[RFC OE-core/meta/lib] BSP Specific Qemurunner

[RFC OE-core/meta/lib] BSP Specific Qemurunner

[Sipke Vriend]

Hi,

This RFC is a proposal to allow BSP layers to setup qemu with their specific
requirements for the testimage oe-core functionality.
The suggested changes will be exercised by the 
bitbake -c testimage <image> 
command.
Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa 
python modules to allow inclusion of python utility scripts in the BSP 
layers.
Any BSP layer wishing to supply their own qemu setup would need to create
an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
The effect is that the lib/oeqa/utils/qemurunner will either allow the 
bsp layer provided <machine>starter to spawn qemu or if not provided, 
spawn qemu via runqemu as currently.
An example bsp layer is available here:
https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
with all required additions in the meta-xilinx/lib directory.

This RFC is triggered by and indirectly related to
Bugzilla report "runqemu shouldn't hard-code machine knowledge"
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827

The following changes since commit cd94dd3d9bba32c3fd55959586128b236d1d4e34:

  security_flags: more relocation issues (2013-12-18 17:23:55 +0000)

are available in the git repository at:

  https://github.com/sipke/oe-core/tree/sipke/qemurunner

Sipke Vriend (6):
  meta:lib:oeqa:utils Allow other layers to have utils in same named
    directory
  meta:lib:oeqa:utils:sshcontrol Allow a non root user for ssh control
  meta:lib:oeqa:utils:targetcontrol Allow for a TEST_USER variable
  meta:lib:oeqa:utils:sshcontrol Allow different port for ssh control
  meta:lib:oeqa:utils:qemurunner Move runqemu code into method
  meta:lib:oeqa:utils:qemurunner Add ability to launch qemu from python
    script

 meta/lib/oeqa/targetcontrol.py    |   11 +++-
 meta/lib/oeqa/utils/__init__.py   |    3 +
 meta/lib/oeqa/utils/qemurunner.py |  121 +++++++++++++++++++++++++++++--------
 meta/lib/oeqa/utils/sshcontrol.py |    8 ++-
 4 files changed, 115 insertions(+), 28 deletions(-)

Cheers
Sipke

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Richard Purdie]

On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
> Hi,
> 
> This RFC is a proposal to allow BSP layers to setup qemu with their specific
> requirements for the testimage oe-core functionality.
> The suggested changes will be exercised by the 
> bitbake -c testimage <image> 
> command.
> Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa 
> python modules to allow inclusion of python utility scripts in the BSP 
> layers.
> Any BSP layer wishing to supply their own qemu setup would need to create
> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
> The effect is that the lib/oeqa/utils/qemurunner will either allow the 
> bsp layer provided <machine>starter to spawn qemu or if not provided, 
> spawn qemu via runqemu as currently.
> An example bsp layer is available here:
> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
> with all required additions in the meta-xilinx/lib directory.
> 
> This RFC is triggered by and indirectly related to
> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827

Why would we do this rather than improve runqemu to be extendable from
BSP layers?

Cheers,

Richard

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Sipke Vriend]

Hi Richard,

>
>-----Original Message-----
>On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
>
>On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
>> Hi,
>> 
>> This RFC is a proposal to allow BSP layers to setup qemu with their specific
>> requirements for the testimage oe-core functionality.
>> The suggested changes will be exercised by the 
>> bitbake -c testimage <image> 
>> command.
>> Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa 
>> python modules to allow inclusion of python utility scripts in the BSP 
>> layers.
>> Any BSP layer wishing to supply their own qemu setup would need to create
>> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
>> The effect is that the lib/oeqa/utils/qemurunner will either allow the 
>> bsp layer provided <machine>starter to spawn qemu or if not provided, 
>> spawn qemu via runqemu as currently.
>> An example bsp layer is available here:
>> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
>> with all required additions in the meta-xilinx/lib directory.
>> 
>> This RFC is triggered by and indirectly related to
>> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
>
>Why would we do this rather than improve runqemu to be extendable from
>BSP layers?
>

Proposing as an additional way to launch qemu for oeqa testimage functionality,
Improving runqemu can and probably should still happen.
 
To consider:
* it keeps testimage functionality (for bsp layers specific things) in 
the lib directly (similar to test cases) and as python.
* testing (via testimage) may have a different requirement to that of
running runqemu on the command line, so an alternate way to launch qemu 
could be useful.
* should this approach of extending the oeqa testimage functionality 
into bsp layers be accepted, this could allow also for bsp specific 
hardware setup for testimage functionality in bsp layers.

Primary aim is a solution which allows the bsp layer to control the 
setup of qemu (and eventually hardware) for testimage functionality. This is 
a proposal towards that goal.

Thanks
Sipke

>Cheers,
>
>Richard
>
>
>
>
>

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Richard Purdie]

On Tue, 2014-01-07 at 22:59 +0000, Sipke Vriend wrote:
> Hi Richard,
> 
> >
> >-----Original Message-----
> >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
> >
> >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
> >> Hi,
> >> 
> >> This RFC is a proposal to allow BSP layers to setup qemu with their specific
> >> requirements for the testimage oe-core functionality.
> >> The suggested changes will be exercised by the 
> >> bitbake -c testimage <image> 
> >> command.
> >> Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa 
> >> python modules to allow inclusion of python utility scripts in the BSP 
> >> layers.
> >> Any BSP layer wishing to supply their own qemu setup would need to create
> >> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
> >> The effect is that the lib/oeqa/utils/qemurunner will either allow the 
> >> bsp layer provided <machine>starter to spawn qemu or if not provided, 
> >> spawn qemu via runqemu as currently.
> >> An example bsp layer is available here:
> >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
> >> with all required additions in the meta-xilinx/lib directory.
> >> 
> >> This RFC is triggered by and indirectly related to
> >> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
> >
> >Why would we do this rather than improve runqemu to be extendable from
> >BSP layers?
> >
> 
> Proposing as an additional way to launch qemu for oeqa testimage functionality,
> Improving runqemu can and probably should still happen.
>  
> To consider:
> * it keeps testimage functionality (for bsp layers specific things) in 
> the lib directly (similar to test cases) and as python.
> * testing (via testimage) may have a different requirement to that of
> running runqemu on the command line, so an alternate way to launch qemu 
> could be useful.
> * should this approach of extending the oeqa testimage functionality 
> into bsp layers be accepted, this could allow also for bsp specific 
> hardware setup for testimage functionality in bsp layers.
> 
> Primary aim is a solution which allows the bsp layer to control the 
> setup of qemu (and eventually hardware) for testimage functionality. This is 
> a proposal towards that goal.

I thought Stefan was already also working on something towards this
goal. I'd like to ensure we don't end up with two things doing the same
thing.

Stefan?

To be clear, I would like to see runqemu enhanced so BSP layers can
extend it, I think that would be useful for everyone. Once we've done
that, I'd like to revisit the qemu abstraction in testimage and figure
out what changes it needs. Some may be required, some may not if we fix
runqemu first, I'm unclear from these commits what those would be
though.

Cheers,

Richard

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Paul Eggleton]

On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote:
> On Tue, 2014-01-07 at 22:59 +0000, Sipke Vriend wrote:
> > Hi Richard,
> > 
> > >-----Original Message-----
> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
> > >
> > >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
> > >> Hi,
> > >> 
> > >> This RFC is a proposal to allow BSP layers to setup qemu with their
> > >> specific requirements for the testimage oe-core functionality.
> > >> The suggested changes will be exercised by the
> > >> bitbake -c testimage <image>
> > >> command.
> > >> Similarly to the oeqa test cases this proposal extends the
> > >> meta/lib/oeqa
> > >> python modules to allow inclusion of python utility scripts in the BSP
> > >> layers.
> > >> Any BSP layer wishing to supply their own qemu setup would need to
> > >> create
> > >> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow the
> > >> bsp layer provided <machine>starter to spawn qemu or if not provided,
> > >> spawn qemu via runqemu as currently.
> > >> An example bsp layer is available here:
> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
> > >> with all required additions in the meta-xilinx/lib directory.
> > >> 
> > >> This RFC is triggered by and indirectly related to
> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
> > >
> > >Why would we do this rather than improve runqemu to be extendable from
> > >BSP layers?
> > 
> > Proposing as an additional way to launch qemu for oeqa testimage
> > functionality, Improving runqemu can and probably should still happen.
> > 
> > To consider:
> > * it keeps testimage functionality (for bsp layers specific things) in
> > the lib directly (similar to test cases) and as python.
> > * testing (via testimage) may have a different requirement to that of
> > running runqemu on the command line, so an alternate way to launch qemu
> > could be useful.
> > * should this approach of extending the oeqa testimage functionality
> > into bsp layers be accepted, this could allow also for bsp specific
> > hardware setup for testimage functionality in bsp layers.
> > 
> > Primary aim is a solution which allows the bsp layer to control the
> > setup of qemu (and eventually hardware) for testimage functionality. This
> > is a proposal towards that goal.
> 
> I thought Stefan was already also working on something towards this
> goal. I'd like to ensure we don't end up with two things doing the same
> thing.
> 
> Stefan?
> 
> To be clear, I would like to see runqemu enhanced so BSP layers can
> extend it, I think that would be useful for everyone. Once we've done
> that, I'd like to revisit the qemu abstraction in testimage and figure
> out what changes it needs. Some may be required, some may not if we fix
> runqemu first, I'm unclear from these commits what those would be
> though.

FWIW I agree, we need to have the BSP-specific functionality in runqemu and 
then what we do with QemuRunner will follow on from that. I think the other 
patches in the series to do with setting user/port should be OK to consider 
independently of this, though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Sipke Vriend]

On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote:
>
>On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote:
>> On Tue, 2014-01-07 at 22:59 +0000, Sipke Vriend wrote:
>> > Hi Richard,
>> > 
>> > >-----Original Message-----
>> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
>> > >
>> > >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
>> > >> Hi,
>> > >> 
>> > >> This RFC is a proposal to allow BSP layers to setup qemu with their
>> > >> specific requirements for the testimage oe-core functionality.
>> > >> The suggested changes will be exercised by the
>> > >> bitbake -c testimage <image>
>> > >> command.
>> > >> Similarly to the oeqa test cases this proposal extends the
>> > >> meta/lib/oeqa
>> > >> python modules to allow inclusion of python utility scripts in the BSP
>> > >> layers.
>> > >> Any BSP layer wishing to supply their own qemu setup would need to
>> > >> create
>> > >> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
>> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow the
>> > >> bsp layer provided <machine>starter to spawn qemu or if not provided,
>> > >> spawn qemu via runqemu as currently.
>> > >> An example bsp layer is available here:
>> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
>> > >> with all required additions in the meta-xilinx/lib directory.
>> > >> 
>> > >> This RFC is triggered by and indirectly related to
>> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
>> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
>> > >
>> > >Why would we do this rather than improve runqemu to be extendable from
>> > >BSP layers?
>> > 
>> > Proposing as an additional way to launch qemu for oeqa testimage
>> > functionality, Improving runqemu can and probably should still happen.
>> > 
>> > To consider:
>> > * it keeps testimage functionality (for bsp layers specific things) in
>> > the lib directly (similar to test cases) and as python.
>> > * testing (via testimage) may have a different requirement to that of
>> > running runqemu on the command line, so an alternate way to launch qemu
>> > could be useful.
>> > * should this approach of extending the oeqa testimage functionality
>> > into bsp layers be accepted, this could allow also for bsp specific
>> > hardware setup for testimage functionality in bsp layers.
>> > 
>> > Primary aim is a solution which allows the bsp layer to control the
>> > setup of qemu (and eventually hardware) for testimage functionality. This
>> > is a proposal towards that goal.
>> 
>> I thought Stefan was already also working on something towards this
>> goal. I'd like to ensure we don't end up with two things doing the same
>> thing.
>> 
>> Stefan?
>> 

Agreed. One solution is desired. Happy to coordinate with and assist Stefan,
either implementing part of a solution (proposed one or another) and/or 
testing whatever Stefan comes up with against our bsp layer.

>> To be clear, I would like to see runqemu enhanced so BSP layers can
>> extend it, I think that would be useful for everyone. Once we've done
>> that, I'd like to revisit the qemu abstraction in testimage and figure
>> out what changes it needs. Some may be required, some may not if we fix
>> runqemu first, I'm unclear from these commits what those would be
>> though.
>
>FWIW I agree, we need to have the BSP-specific functionality in runqemu and 
>then what we do with QemuRunner will follow on from that. I think the other 

Hopefully the BSP-specific parts (config files or scripts) will be in the bsp
layer.
Is the ETA of this still 1.6-M4?

>patches in the series to do with setting user/port should be OK to consider 
>independently of this, though.
>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre
>
>

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Stanacar, StefanX]

On Thu, 2014-01-09 at 00:01 +0000, Sipke Vriend wrote:
> On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote:
> >
> >On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote:
> >> On Tue, 2014-01-07 at 22:59 +0000, Sipke Vriend wrote:
> >> > Hi Richard,
> >> > 
> >> > >-----Original Message-----
> >> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
> >> > >
> >> > >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
> >> > >> Hi,
> >> > >> 
> >> > >> This RFC is a proposal to allow BSP layers to setup qemu with their
> >> > >> specific requirements for the testimage oe-core functionality.
> >> > >> The suggested changes will be exercised by the
> >> > >> bitbake -c testimage <image>
> >> > >> command.
> >> > >> Similarly to the oeqa test cases this proposal extends the
> >> > >> meta/lib/oeqa
> >> > >> python modules to allow inclusion of python utility scripts in the BSP
> >> > >> layers.
> >> > >> Any BSP layer wishing to supply their own qemu setup would need to
> >> > >> create
> >> > >> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
> >> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow the
> >> > >> bsp layer provided <machine>starter to spawn qemu or if not provided,
> >> > >> spawn qemu via runqemu as currently.
> >> > >> An example bsp layer is available here:
> >> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
> >> > >> with all required additions in the meta-xilinx/lib directory.
> >> > >> 
> >> > >> This RFC is triggered by and indirectly related to
> >> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
> >> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
> >> > >
> >> > >Why would we do this rather than improve runqemu to be extendable from
> >> > >BSP layers?
> >> > 
> >> > Proposing as an additional way to launch qemu for oeqa testimage
> >> > functionality, Improving runqemu can and probably should still happen.
> >> > 
> >> > To consider:
> >> > * it keeps testimage functionality (for bsp layers specific things) in
> >> > the lib directly (similar to test cases) and as python.
> >> > * testing (via testimage) may have a different requirement to that of
> >> > running runqemu on the command line, so an alternate way to launch qemu
> >> > could be useful.
> >> > * should this approach of extending the oeqa testimage functionality
> >> > into bsp layers be accepted, this could allow also for bsp specific
> >> > hardware setup for testimage functionality in bsp layers.
> >> > 
> >> > Primary aim is a solution which allows the bsp layer to control the
> >> > setup of qemu (and eventually hardware) for testimage functionality. This
> >> > is a proposal towards that goal.
> >> 
> >> I thought Stefan was already also working on something towards this
> >> goal. I'd like to ensure we don't end up with two things doing the same
> >> thing.
> >> 
> >> Stefan?
> >> 
> 
> Agreed. One solution is desired. Happy to coordinate with and assist Stefan,
> either implementing part of a solution (proposed one or another) and/or 
> testing whatever Stefan comes up with against our bsp layer.

I'm sorry for replying so late, this has been a slow week. I'm a bit
confused because last time I checked I wasn't working on something
similar :) (layer-controlled qemu/bsp setup), but I'm happy to help.

I've looked at the patches themselves, and they are okay, but I'm not
sure a layer-specific qemu setup for testimage is what we should do in
the long term. Now, I can see the problem you are trying to fix here and
why you need this... I always assumed that a BSP layer is mostly about
real hw and that runqemu will deal with any qemu machine. So, as Richard
said, we should probably fix runqemu.

Now, I really like the idea of a layer-controlled/extendable target
setup (be it qemu or hardware) and I think we should allow a layer to
extend lib/oeqa/targetcontrol.py and provide (or extend) its own
TEST_TARGET (besides qemu and simpleremote). That will prove more useful
for hw stuff and it will allow a layer to completely control deployment
of a qemu target too (deploy, start, stop, running commands, etc). E.g:
perhaps a layer doesn't like the use of the ext3 images for qemu and
needs to use something else. Thoughts?

Cheers,
Stefan

Re: [RFC OE-core/meta/lib] BSP Specific Qemurunner

[Sipke Vriend]

Hi Stefan,

On Thursday, 9 January 2014 10:19 PM, Stanacar, StefanX wrote:
>On Thu, 2014-01-09 at 00:01 +0000, Sipke Vriend wrote:
>> On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote:
>> >
>> >On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote:
>> >> On Tue, 2014-01-07 at 22:59 +0000, Sipke Vriend wrote:
>> >> > Hi Richard,
>> >> > 
>> >> > >-----Original Message-----
>> >> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote:
>> >> > >
>> >> > >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote:
>> >> > >> Hi,
>> >> > >> 
>> >> > >> This RFC is a proposal to allow BSP layers to setup qemu with their
>> >> > >> specific requirements for the testimage oe-core functionality.
>> >> > >> The suggested changes will be exercised by the
>> >> > >> bitbake -c testimage <image>
>> >> > >> command.
>> >> > >> Similarly to the oeqa test cases this proposal extends the
>> >> > >> meta/lib/oeqa
>> >> > >> python modules to allow inclusion of python utility scripts in the BSP
>> >> > >> layers.
>> >> > >> Any BSP layer wishing to supply their own qemu setup would need to
>> >> > >> create
>> >> > >> an appropriate meta-bsplayer/lib/oeqa/utils/<machine>starter.py
>> >> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow the
>> >> > >> bsp layer provided <machine>starter to spawn qemu or if not provided,
>> >> > >> spawn qemu via runqemu as currently.
>> >> > >> An example bsp layer is available here:
>> >> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner
>> >> > >> with all required additions in the meta-xilinx/lib directory.
>> >> > >> 
>> >> > >> This RFC is triggered by and indirectly related to
>> >> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge"
>> >> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827
>> >> > >
>> >> > >Why would we do this rather than improve runqemu to be extendable from
>> >> > >BSP layers?
>> >> > 
>> >> > Proposing as an additional way to launch qemu for oeqa testimage
>> >> > functionality, Improving runqemu can and probably should still happen.
>> >> > 
>> >> > To consider:
>> >> > * it keeps testimage functionality (for bsp layers specific things) in
>> >> > the lib directly (similar to test cases) and as python.
>> >> > * testing (via testimage) may have a different requirement to that of
>> >> > running runqemu on the command line, so an alternate way to launch qemu
>> >> > could be useful.
>> >> > * should this approach of extending the oeqa testimage functionality
>> >> > into bsp layers be accepted, this could allow also for bsp specific
>> >> > hardware setup for testimage functionality in bsp layers.
>> >> > 
>> >> > Primary aim is a solution which allows the bsp layer to control the
>> >> > setup of qemu (and eventually hardware) for testimage functionality. This
>> >> > is a proposal towards that goal.
>> >> 
>> >> I thought Stefan was already also working on something towards this
>> >> goal. I'd like to ensure we don't end up with two things doing the same
>> >> thing.
>> >> 
>> >> Stefan?
>> >> 
>> 
>> Agreed. One solution is desired. Happy to coordinate with and assist Stefan,
>> either implementing part of a solution (proposed one or another) and/or 
>> testing whatever Stefan comes up with against our bsp layer.
>
>I'm sorry for replying so late, this has been a slow week. I'm a bit
>confused because last time I checked I wasn't working on something
>similar :) (layer-controlled qemu/bsp setup), but I'm happy to help.
>

No worries, you're not late and sorry for having inadvertently dragged 
you in it seems :)

>I've looked at the patches themselves, and they are okay, but I'm not
>sure a layer-specific qemu setup for testimage is what we should do in
>the long term. 
>Now, I can see the problem you are trying to fix here and
>why you need this... I always assumed that a BSP layer is mostly about
>real hw and that runqemu will deal with any qemu machine. So, as Richard
>said, we should probably fix runqemu.
>

Ok, let's fix runqemu for qemu setup, and see from that whether any 
changes are required within qemurunner.py or not. I can envisage there 
might be to remove some dependencies on infrastructure setup, 
but will not know for sure till the work is started.
Has someone started and is there a branch available to track this work?

>Now, I really like the idea of a layer-controlled/extendable target
>setup (be it qemu or hardware) and I think we should allow a layer to
>extend lib/oeqa/targetcontrol.py and provide (or extend) its own
>TEST_TARGET (besides qemu and simpleremote). That will prove more useful
>for hw stuff and it will allow a layer to completely control deployment
>of a qemu target too (deploy, start, stop, running commands, etc). E.g:
>perhaps a layer doesn't like the use of the ext3 images for qemu and
>needs to use something else. Thoughts?
>

Great, I like it. Will give it some more thought, but even the simple
addition of allowing a bsp layer to provide its own TEST_TARGET class is a
great step forward.

Thanks
Sipke


>Cheers,
>Stefan
>