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

[Cyril Hrubis]

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.

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

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

-- 
Cyril Hrubis
chrubis@suse.cz