[LTP] [PATCH v2 2/3] tst_test: Print environment variables on -h

[Petr Vorel]

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