From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Sebastian Chlad <sebastian.chlad@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once
Date: Wed, 18 Mar 2026 16:40:19 +0100 [thread overview]
Message-ID: <20260318154019.GE31214@pevik> (raw)
In-Reply-To: <abqZ3h1iVo5DaQ_4@yuki.lan>
Hi Cyril,
> Hi!
> > It's a bit more complicated we do not have only iterations but also
> > duration and timeout per iteration. So we would need a function that
> > would return if the script should continue or not and also call the
> > heartbeat() function. Something as:
> > int tst_next_shell_iteration(void)
> > {
> > int cont = 0;
> > static int iteration = 0;
> > if (iteration < iterations)
> > cont = 1;
> > if (stop_time && get_time_ms() < stop_time())
> > cont = 1;
> > if (!cont)
> > return 0;
> > heartbeat();
> > return ++iteration;
> > }
> > The shell helper would call this and we would use it in tst_run.sh and
> > loop the tst_test() until we are said to stop.
Wait, tst_run_shell.c calls shell script via tst_run_script(). This can be
called only once, before starting the script...
> Note also that this solution would move the iteration into the shell
... but from the code it's obvious that you want to call it more times.
How do you want to reach C library code from shell test?
> script, since if we do not iterate in the shell, we will end up with a
> different environment in the second and subsequent iterations. That
> means that any variables exported in setup() would be lost in subsequent
> iterations, the pid of the shell would be different, etc.
Yes, I noticed that during du01.sh rewrite. I was surprised but thought that you
wanted to have most of the library code be in C API (having shell part of the
shell loader really thin).
Before sending the patchset I was thinking if some shell variables should be
shared and exported into new shell run. But it'd be unpractical and as you write
PID of the shell would be always different.
I have to admit sometimes I think whether rewriting everything into C wouldn't
be a better time investment than implementing shell loader, given we are going
to redesign network API. Anyway, any new test should really be using C API.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-18 15:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 14:25 [LTP] [PATCH 0/6] [RFC,WIP] shell loader fixes + du01.sh rewrite Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments Petr Vorel
2026-03-17 7:36 ` Li Wang via ltp
2026-03-18 14:17 ` Cyril Hrubis
2026-03-18 15:10 ` Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh Petr Vorel
2026-03-17 7:54 ` Li Wang via ltp
2026-03-18 14:26 ` Cyril Hrubis
2026-03-18 15:02 ` Petr Vorel
2026-03-20 16:20 ` Cyril Hrubis
2026-03-23 12:06 ` Petr Vorel
2026-03-23 12:41 ` [LTP] isofs.sh rewrite [was Re: [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh] Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 3/6] shell_loader: Start test count from 1 Petr Vorel
2026-03-17 8:00 ` Li Wang via ltp
2026-03-13 14:25 ` [LTP] [RFC][PATCH 4/6] run_shell_tcnt: Add test count also for test_all Petr Vorel
2026-03-17 9:45 ` Li Wang via ltp
2026-03-13 14:25 ` [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once Petr Vorel
2026-03-17 9:42 ` Li Wang via ltp
2026-03-18 11:23 ` Cyril Hrubis
2026-03-18 12:26 ` Cyril Hrubis
2026-03-18 15:40 ` Petr Vorel [this message]
2026-03-20 15:15 ` Cyril Hrubis
2026-03-23 21:20 ` Petr Vorel
2026-03-13 14:26 ` [LTP] [PATCH 6/6] du01.sh: Rewrite into shell loader Petr Vorel
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=20260318154019.GE31214@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=sebastian.chlad@suse.com \
/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