[LTP] [PATCH v2 2/3] tst_test: Print environment variables on -h
Petr Vorel
pvorel@suse.cz
Tue Dec 14 19:54:49 CET 2021
Hi Tim,
> > -----Original Message-----
> > From: Petr Vorel <pvorel@suse.cz>
> > > Hi Tim,
> > > > > + fprintf(stderr, "LTP_TIMEOUT_MUL Multiply timeout (must be number >= 1)\n");
> > > > I think this should this be: "Timeout multiplier (must be a number >=1, should be an integer)
> > > Also makes sense, thanks!
> > Although it does not have to be integer.
> > => "Timeout multiplier (must be a number >=1"
> > For C API it's used any value:
> > ./open01
> > tst_test.c:1409: TINFO: Timeout per run is 0h 05m 00s
> > LTP_TIMEOUT_MUL=1.15 ./open01
> > tst_test.c:1409: TINFO: Timeout per run is 0h 05m 45s
> When I grepped the source code I saw the usage in testcases/lib/tst_test.sh,
> but somehow missed the usage in lib/tst_test.c (sloppy on my part!)
FYI this help is for C API. We should print variables also in shell API,
but I wanted to keep this patchset small.
> Thanks for pointing this out.
> > For shell API:
> > ./zram02.sh
> > zram02 1 TINFO: timeout per run is 0h 5m 0s
> > zram02 1 TINFO: timeout per run is 0h 7m 30s
> > LTP_TIMEOUT_MUL=1.15 ./zram02.sh
> > zram02 1 TINFO: ceiling LTP_TIMEOUT_MUL to 2
> > zram02 1 TINFO: timeout per run is 0h 10m 0s
> > zram02 1 TINFO: timeout per run is 0h 15m 0s
> > Doc [1] explain it: Variable is also used in shell tests, but ceiled to int.
> Would it be useful to add a bit of code to tst_test.sh to handle
> floating point? The shell construct of '$((timeout * LTP_TIMEOUT_MUL))'
> can't handle floating point, but floating point could be done pretty easily
> with a callout to awk or bc.
> I'm willing to look at this and submit a patch. But does the shell
> test system try to avoid dependencies on other utility programs (like awk or bc)?
> Maybe rounding timeouts up is preferred behavior anyway, so
> this is not needed. What do you think?
[ Cc Joerg, Li and Cyril, who were involved in shell timeout ]
We spent quite a lot of time before we end-up with ceiling, I'd have to search
for the reasons. We also didn't think that it's a big problem to not being
precise on shell. But feel free to improve things. Just, generally we prefer to
wrote small C code instead adding new dependencies (bc etc) or trying to make
shell portable. Actually writing C parser would be few lines of code.
> In any event, I retract my "should be an integer" suggestion. :-)
You pointed out also wrong spelling, which I'm going to update.
Thanks a lot for your review!
Kind regards,
Petr
> -- Tim
More information about the ltp
mailing list