Hi Stefan, On Thursday, 9 January 2014 10:19 PM, Stanacar, StefanX wrote: >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. >
No worries, you're not late and sorry for having inadvertently dragged you in it seems :) >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. > Ok, let's fix runqemu for qemu setup, and see from that whether any changes are required within qemurunner.py or not. I can envisage there might be to remove some dependencies on infrastructure setup, but will not know for sure till the work is started. Has someone started and is there a branch available to track this work? >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? > Great, I like it. Will give it some more thought, but even the simple addition of allowing a bsp layer to provide its own TEST_TARGET class is a great step forward. Thanks Sipke >Cheers, >Stefan > _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
