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