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

[Petr Vorel]

> 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...

> The tst_run_script() is set as the tst_test.test or tst_test.test_all
> function. Then we enter the library via the tst_run_tcases() and we do
> the full test library init and everything.

> The problem with that is that we run the shell script is re-executed
> for each -i iteration. That means that unlike the fork() the whole
> environment is re-created. So we cannot run setup() only for first
> iteration as we do for C.

> So we either call the setup in each iteration (that means both tcnt and
> -i) or we push the loop over tcnt and -i into the shell. I think that
> more elegant solution is the latter.

Agree.

> > > 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?

> We would have to just call the tst_test->test() function directly in the
> fork_testrun() instead of testrun() for script tests. That would avoid
> all the looping and heartbeats() in C library in that case.

+1. My question was answered by "use C helper to read iteration from shared
memory".

> > > 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.

> I think that the shell API is nearly finished at this point, the last
> unsolved piece is how we design the test iterations with -i and tcnt.

We need also getopts which we will also have to be handled in shell because we
actually execute the shell. Then timeout handling (LTP_TIMEOUT_MUL, LTP_RUNTIME_MUL),
but that should be part of the function you suggested for iteration.

Hopefully that's all and shell loader will be kept thin, but you know, the devil
is hidden in detail.

Kind regards,
Petr