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

[Paul Eggleton <paul.eggleton@linux.intel.com>]

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