All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tudor Florea <tudor.florea@enea.com>
To: "Aníbal Limón" <anibal.limon@linux.intel.com>,
	openembedded-core@lists.openembedded.org
Cc: paul.eggleton@linux.intel.com, poky@yoctoproject.org,
	benjamin.esquivel@intel.com, georgex.l.musat@intel.com
Subject: Re: [PATCH v3 0/3] ptest-runner 2.0
Date: Wed, 6 Jan 2016 23:05:06 +0200	[thread overview]
Message-ID: <568D8182.7080308@enea.com> (raw)
In-Reply-To: <568D3BC3.6040607@linux.intel.com>

Hi Alimon
See inline.
Tudor.

On 06/01/2016 18:07, Aníbal Limón wrote:
> Hi again Tudor,
> 
> Comments below,
> 
> alimon
> 
> 
> 
> On 01/06/2016 09:46 AM, Aníbal Limón wrote:
>> Hi Todor,
>> 
>> Comments below, alimon
>> 
>> 
>> On 01/05/2016 06:13 PM, Tudor Florea wrote:
>>> Hi Anibal, Please see my comments inline. Regards, Tudor.
>>> 
>>> On 04/01/2016 20:29, Aníbal Limón wrote:
>>>> The whole set is sent to two ML for reviewing purposes the
>>>> first two patches are for oe-core and the last one for poky.
>>>> 
>>>> The first two commits (oe-core) adds a new ptest-runner
>>>> written in python the sh one is conserved to use in tiny
>>>> systems.
>>>> 
>>>> What's new in ptest runner:
>>>> 
>>>> - Monitor/timeout stdout, stderr of the test suite to avoid
>>>> block indefinetly.
>>> This is definitely something useful.
>>>> - Add option for change ptest root directory. - Add option
>>>> for list available tests. - Add option for only run certain
>>>> tests.
>>>> 
>>>> The last commit (meta-yocto) sets ptest-runner to 1.0 in
>>>> poky-tiny systems due to python dependency.
>>> I think adding python dependency is a shift in a wrong
>>> direction for for ptest-runner. The assumption that most
>>> embedded devices (tiny or not) have python might not be
>>> correct. The alternative of using the old version of
>>> ptest-runner only complicate things. I do think this kind of
>>> work is really useful but this should be done into a testing
>>> framework that runs outside of the DUT.
>> 
>> The original problem is the current sh ptest-runner blocks
>> indefinitely when a package ptest blocks (we don't control this),
>> now python-ptest is blocking the ptest-runner, see [1]. The way
>> to solve this is adding timeout in some place.
>> 
>> I know that bash support timeout option but this option works
>> over the whole process making us to define timeouts too big or
>> per machine/device also tiny systems mainly don't use bash.
>> That's the reason for i decide to write python version of
>> ptest-runner that applies a timeout over the output of the
>> program give us better control/granularity over the running
>> ptest.
>> 
>> 
>> If you now other way to solve the problem please tell us.
We may have to use our own version of timeout as we cannot rely on
bash either. A good starting point is here:
http://www.pixelbeat.org/scripts/timeout

I'm thinking this is a good opportunity to improve ptest-runner to run
the package tests in parallel. That is, we could spawn a shell per
each run-ptest (wrapper) that have the output redirected to its own
file  (e.g. /var/log/ptest/{package}/output) and then we only timeout
monitoring the output file.
In future we may eventually mimic the logic of automake parallel test
harness
(https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html)

> 
> I was thinking and one possible solution for this will be implement
> in C the ptest-runner with the same features of python version, any
> comment?
That would be great!
> 
> 
>> 
>> 
>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8021
>> 
>> 
>>>> 
>>>> The changes are available in the git repository at:
>>>> 
>>>> git://git.yoctoproject.org/poky-contrib alimon/ptest-runner 
>>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/ptest-runner
>>>>
>>>>
>>>> 
Aníbal Limón (3): ptest-runner: Add version 2.0 re-implementation
>>>> in python. ptest-runner: Add a recipe for install
>>>> ptest-runner 2.0. conf/distro/poky-tiny.conf: Add default
>>>> install of ptest-runner 1.0
>>>> 
>>>> meta-yocto/conf/distro/poky-tiny.conf              |   4 + 
>>>> .../ptest-runner/files/ptest-runner_2.0.py         | 162 
>>>> +++++++++++++++++++++ .../ptest-runner/ptest-runner_2.0.bb |
>>>> 27 ++++ 3 files changed, 193 insertions(+) create mode
>>>> 100755 
>>>> meta/recipes-support/ptest-runner/files/ptest-runner_2.0.py
>>>> create mode 100644
>>>> meta/recipes-support/ptest-runner/ptest-runner_2.0.bb
>>>> 


      reply	other threads:[~2016-01-06 21:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 18:29 [PATCH v3 0/3] ptest-runner 2.0 Aníbal Limón
2016-01-04 18:29 ` [PATCH v3 1/3] ptest-runner: Add version 2.0 re-implementation in python Aníbal Limón
2016-01-04 18:29 ` [PATCH v3 2/3] ptest-runner: Add a recipe for install ptest-runner 2.0 Aníbal Limón
2016-01-04 18:29 ` [PATCH v3 3/3] conf/distro/poky-tiny.conf: Add default install of ptest-runner 1.0 Aníbal Limón
2016-01-06  0:13 ` [PATCH v3 0/3] ptest-runner 2.0 Tudor Florea
2016-01-06 15:46   ` [OE-core] " Aníbal Limón
2016-01-06 15:46     ` Aníbal Limón
2016-01-06 16:07     ` [OE-core] " Aníbal Limón
2016-01-06 16:07       ` Aníbal Limón
2016-01-06 21:05       ` Tudor Florea [this message]

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=568D8182.7080308@enea.com \
    --to=tudor.florea@enea.com \
    --cc=anibal.limon@linux.intel.com \
    --cc=benjamin.esquivel@intel.com \
    --cc=georgex.l.musat@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=poky@yoctoproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.