public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] runltp-ng hackweek experiment
Date: Tue, 28 Feb 2017 15:29:12 +0100	[thread overview]
Message-ID: <20170228142912.GA13189@rei.lan> (raw)

Hi!
I've tried to experiment with a proof of concept for new LTP test
execution framework during Hackweek[1]. And I've ended up with something
that is more or less usable and has features missing in runltp + ltp-pan
script we have now.

It's in the proof of concept state at this point and polishing it would
require more work, but it looks promising at this point.

The key desing points are:

* We use the ltp-wrapper[2] instead of ltp-pan, which runs oldlib and
  openposix testcases from a test() function from a newlib test.

  This provides us test timeouts and killing whole test process tree,
  etc. basically for free.

* The ltp-runner[3] then does the runtest files parsing, openposix test
  discovery, test execution, writing test results, etc.

  - The one intrusive change is that I've added code to both oldlib and
    newlib to support '-q' flag, so that we can query test for details
    i.e. if it's oldlib/newlib test, if it requires root, etc. This is
    would be also needed for parallel test execution, where the test
    would report if it can be executed in parallel and/or report what
    kind of system resources it monopolizes. The bottom line is that
    all testcases should understand the -q option and at least exit
    without writing any output, which is not the case at the moment.

  - The code is split into several modules, the parsers prepare list of
    tests to be executed, then there is code to execute the tests and
    store logs, then the output writers can produce logs in several
    different formats. I've experimented a bit with a better html
    output[4][5] (table sorting is not implemented yet, but planned).

  - The code is prepared for parallel test execution which is not
    implemented at the moment but basically boils down to marking
    down testcases that cannot be executed concurently. As I wrote
    I would like to keep this information inside the test code and
    export it via the -q options.

  - We miss random test execution and execute tests for defined amount
    of time at this point, but other than that the basic features are
    there.

And as usuall any comments are welcomed ;-).

[1] https://hackweek.suse.com/
[2] https://github.com/metan-ucw/ltp/blob/master/tools/runltp-ng/bin/ltp-wrapper.c
[3] https://github.com/metan-ucw/ltp/blob/master/tools/runltp-ng/bin/ltp-runner.c
[4] http://metan.ucw.cz/outgoing/ltp-openposix.html
[5] http://metan.ucw.cz/outgoing/ltp-syscalls.html

-- 
Cyril Hrubis
chrubis@suse.cz

             reply	other threads:[~2017-02-28 14:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 14:29 Cyril Hrubis [this message]
2017-03-01 10:11 ` [LTP] runltp-ng hackweek experiment Petr Vorel
2017-03-01 10:35   ` Cyril Hrubis
2017-03-01 11:55     ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170228142912.GA13189@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox