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

["Stanacar, StefanX" <stefanx.stanacar@intel.com>]

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