[CRIU] [RFC PATCH 17/21] zdtm: add the multi-test launcher

Andrew Vagin avagin at virtuozzo.com
Wed Mar 9 10:55:12 PST 2016


On Wed, Mar 09, 2016 at 01:33:16PM +0300, Pavel Emelyanov wrote:
> On 02/19/2016 05:50 PM, Ivan Shapovalov wrote:
> > This program works as a "host" to multiple test binaries, which are
> > loaded into the same address space and then executed all at once.
> > 
> > The launcher tries to avoid using threads (to reduce probability of
> > affecting the test results) and we do not alter the tests themselves.
> > Instead, we hook various functions in libzdtmtst and use <ucontext.h>
> > to redirect execution flow between the launcher and tests.
> > 
> > That is, first we run each test from start of their main() up to entry
> > to test_init(), where each test is interrupted and contexts are saved.
> > After all tests have been run to that point, real test_init() is
> > performed "once and for all". The same method is used repeatedly for all
> > phases of tests' execution.
> > 
> > The only case when we use threads is when some of tests want to run a
> > busy loop during C/R. In this case we spawn a thread (using clone(), not
> > pthreads) for each such test. After C/R we join all threads and do
> > verification in the usual sequential mode.
> 
> Andrey, Cyrill, please, share your thoughts -- the approach here it
> to hijack the compiled test binaries and manually jump the code around
> them. Instead of patching the test .c-s to prepare them for being
> launched as (at least) .so-s. Which way would be more preferred?

Looks like this approach doesn't affect original binaries and we just
add an executer for a group of tests. If it's true, I like it.
And I like the idea to run all tests in a context of one process.

In addition I like this approach because it looks like a hack and it
isn't ugly.

> 
> -- Pavel
> 


More information about the CRIU mailing list