[OE-core] [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