From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 5/7] tst_test.sh: Introduce tst_set_timeout(timeout)
Date: Tue, 2 Mar 2021 11:17:18 +0100 [thread overview]
Message-ID: <YD4QrlVCIJOYj0ze@pevik> (raw)
In-Reply-To: <CAEemH2cr0TFvFiis_05Fh4bEe1ZUmFtMO5ysYFped5ZQYucvAg@mail.gmail.com>
Hi Li,
...
> > +tst_set_timeout()
> > +{
> > + TST_TIMEOUT="$1"
> Not sure if we should check "$1" is valid again before using it.
General check for int is done in _tst_setup_timer, but that's not what you mean.
> I guess in most scenarios, the function is invoked by tests, so
> just needs to guarantee $1 > $TST_TIMEOUT, otherwise, it
> looks meaningless to reset TST_TIMEOUT?
> (especially to avoid people set a smaller value by a typo)
I thought it's not necessary. TST_TIMEOUT is meant to be set in the test. But we
currently don't check for that (it can be wrongly set as environment variable)
and it'd be difficult to check that (I'd prefer not grep $TST_TEST_PATH, because
that would not work for shell libraries (e.g. zram_lib.sh).
The main reason for me is that C API allows to set lower value in the code, thus
I didn't want to prevent it in the shell => it'd be a diverse from C API.
We could add warning: "don't set TST_TIMEOUT" in docs and print warning/reset it
in runltp and runltp-ng, but that would not protect when running test itself.
It's really hard trying to have at least similar API with two fairly different
languages :).
Kind regards,
Petr
next prev parent reply other threads:[~2021-03-02 10:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 22:02 [LTP] [PATCH 0/7] zram cleanup, tst_set_timeout(timeout) Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 1/7] zram: Calculate dev_num variable Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 2/7] zram01.sh: Generate test setup variables in setup Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 3/7] zram: Add zram_compress_alg() to zram02.sh Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 4/7] zram: Move test specific functions out of zram_lib.sh Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 5/7] tst_test.sh: Introduce tst_set_timeout(timeout) Petr Vorel
2021-03-02 8:53 ` Li Wang
2021-03-02 10:04 ` Cyril Hrubis
2021-03-02 10:26 ` Petr Vorel
2021-03-02 13:50 ` Li Wang
2021-03-02 10:17 ` Petr Vorel [this message]
2021-03-01 22:02 ` [LTP] [PATCH 6/7] tst_test.sh: Run cleanup also after test timeout Petr Vorel
2021-03-02 8:59 ` Li Wang
2021-03-02 10:20 ` Petr Vorel
2021-03-11 13:49 ` Cyril Hrubis
2021-03-11 14:47 ` Petr Vorel
2021-03-01 22:02 ` [LTP] [PATCH 7/7] zram: Increase timeout according to used devices Petr Vorel
2021-03-02 9:07 ` Li Wang
2021-03-11 13:30 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YD4QrlVCIJOYj0ze@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox