[LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once

[Petr Vorel]

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