[LTP] Test library API changes

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > > 2. Can we keep ltp_syscall() and call correct brk func with some magic?
> > 
> > Well we can split the header as we did with the rest of them, do you
> > think that it's worth of it?
> 
> I was thinking some ifdef magic. It has same signature in both
> versions of API, so adding new function with different name,
> that does pretty much the same seems like unnecessary complication.

My reasoning was different. There are only two functions that start with
ltp_ in the library the ltp_syscall and ltp_clone. So the reason for
rename is unifying on tst_ and it was convinient in this case as well.
But I do not care that much about this. If you think keeping
ltp_syscall() is better, then we can go for it.

> > > 5c) What if we stored ipc path to env variable?
> > > 
> > > setup_ipc
> > >   generates tmp name based on test name: ltp_ipc_path
> > >   for convenience will initialize also envp array:
> > >     ltp_only_ipc_env[] = { "LTP_IPC_PATH="$ltp_ipc_path, NULL }
> > >   creates ipc file
> > 
> > Hmm, that way the test would have to explicitly pass it to the execve().
> 
> True, but it would be rare, as you said it's for ~10 testcases.
> 
> > 
> > I would rather make it reasonably unique but decideable without
> > explicitly passing variables around.
> 
> Should we consider multiple instances running at a time? I do
> recall that tools/pounder21 allows running things in parallel.
> (Not sure if anyone runs more instances of same test though)

I think that disabling the possibility just to make writing the test
library a bit easier is pretty bad idea. Most of the testcases we have
can run in parallel just fine. There are only a few that stress the
system to the limit or use global resources (devices, IPC, change system
time, ...) and if we anotate these tests we can easily speed up the test
run five times just by running most of the testcases in parallel.

-- 
Cyril Hrubis
chrubis@suse.cz