[OE-core] Make runqemu knows nothing about machine

[Robert Yang]

On 04/29/2016 05:45 PM, Richard Purdie wrote:
> On Tue, 2016-04-26 at 11:42 +0800, Robert Yang wrote:
>> Hello,
>>
>> The qemu-native can boot a lot of machines, but oe-core's runqemu can
>> only
>> boot a few of them which are hardcoded into runqemu. I'd like to
>> change
>> it little to make it drop the hardcode and can boot more machines.
>> Here
>> are some basic thoughts, please feel free to give your comments.
>>
>> runqemu is a helpful script which can help us boot images easily, but
>> it
>> has a lot of hard code for machine + args. I'd like to remove these
>> from
>> runqemu, and make it as a frame. The logical is that, who knows
>> clearly
>> about whether qemu can boot the machine and how to boot it (args),
>> the
>> answer is the machine/bsp developer, so we can:
>>
>> * Add a var like QEMU_SUPPORTED = "yes/no" in the bsp conf file
>> (default to no)
>> * Add a var like QEMU_BOOT_ARGS = "foo" if there are special args.
>> * Let do_rootfs or do_image_foo write data such as QEMU_BOOT_ARGS to
>>     DEPLOY_DIR_IMAGE/runqemu/ or tmp/deploy/images/runqemu/, we can
>> treat
>>     the "runqemu/" dir as a database, and anything we need there, for
>> example,
>>     efi/pcbios, root args, and so on. We won't miss anything since all
>> the
>>     images which can be boot by runqemu are built by oe-core.
>> * Then we can easily add supported machine to runqemu from the bsp
>> itself
>>     without change runqemu.
>>
>> I will start working on it if there is no objections, and make sure
>> it won't
>> break any current supported machines.
>
> I guess we have some decisions to make. Firstly, is that script better
> in shell or python at this point? Originally, shell made sense but I'm
> starting to wonder if it would be clearer in python.
>
> If we left it as shell, I'd envisaged it going through something like
> BBPATH and sourcing files from each of the layers to build up its own
> list of supported machines. The trouble is we can't easily get BBPATH
> in the shell environment since we can't assume bitbake and we ideally
> want it to work outside of our build environment.

Thanks for the reply, my thought is that move part of the implementation
into a class called runqemu.bbclass (or other names), and leave the runqemu
as a shell script, when QEMU_BOOT_SUPPORTED = "1", runqemu.bbclass will
create a:
tmp/deploy/images/<machine>/runqemu

And the content in runqemu can be: (for example, arm)
QEMU="/path/to/sysroots/x86_64-linux/usr/bin/qemu-system-arm -m 128 -machine 
versatilepb  "
TUNE_ARCH="arm"
QEMU_DEFAULT_KERNEL="zImage-qemuarm.bin"
QEMU_DEFAULT_FSTYPE="ext4"
QEMU_MEM="-m 128"
[maybe more]

All of these variables can be defined in bsp layer or conf files. I will
add some default values there according to TUNE_ARCH, so that the bsp may
not need do anything to boot from qemu when QEMU_BOOT_SUPPORTED = "1".

// Robert

>
> With the development of devtool, I'm wondering if runqemu should become
> another such "command", written in python and working in any of the
> environments we'd expect devtool to work (eSDK, main build). If we did
> that, we'd have the layers and could easily access BBPATH and search
> for additional modules to add support for additional machines.
>
> Thoughts?
>
> Cheers,
>
> Richard
>
>
>