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 > > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
