Re: [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Robert Yang <liezhi.yang@windriver.com>]

On 06/23/2016 04:17 PM, Richard Purdie wrote:
> Hi Robert,
>
> On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
>> This is still WIP, I send this out to make sure that I won't walk on
>> wrong way too far. Please feel free to give any comments.
>>
>> TODO:
>> * Update the one which uses runqemu, such as oeqa
>> * Boot EFI image
>> * Boot multilib image such as lib32-foo
>> * Change the vars name such as QEMU_SYSTEM_OPTIONS and
>>    QEMU_SECOND_SERIAL_OPT
>> * More testing
>>
>>
>> === Taken from patch 8/8's commit message:
>> * Why refactor
>>    The old runqemu had hardcoded machine knowledge, which limited its
>>    usage, for example, qemu-system-foo can boot the target, but
>> runqemu
>>    can't, and we need edit runqemu/runqemu-internal a lot to support
>> boot
>>    it.
>>
>> * Brief introduction on implemention
>>    The basic thought is that, machine/bsp developer knows clearly on
>>    whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1"
>> or
>>    "0"), and how to boot it, so we leave these settings in the
>> machine's
>>    configuration.
>>    - qemu-boot.bbclass will write machine's info to
>>      ${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.
>>    - We need use "runqemu -m <machine>" rather than "runqemu
>> <machine>"
>>      since the scripts knows nothing about machine any more, and the
>>      similar to other old options, this is good for future's
>> extension.
>>    - I have updated all the machine's configuration except qemush4,
>> since
>>      I can't find this machine anywhere.
>>    - Several machines such as genericx86 and genericx86-64 can be boot
>> by
>>      new runqemu without any changes.
>>    - Added help info for supported options such as slirp and audio.
>>
>> * Usage
>> Usage: runqemu <options>
>>      -m <machine>, specify machine
>>      -k <kernel>, specify kernel
>>      -r <rootfs>, specify disk image, rootfs or nfs dir
>>      -t <fstype>, specify fstypes, supported types:
>>                   ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio,
>> hddimg,
>>                   hdddirect, vmdk, wic, qcow2, vdi
>>      -n, nographic, disables video console
>>      -K, enable KVM when running x86 and x86-64 (VT-capable CPU
>> required)
>>      -V, enables KVM with VHOST support when running x86 and x86-64
>> (VT-capable CPU required)
>>      -v, publicvnc - enable a VNC server open to all hosts
>>      -u, slirp mode, use user mode networking (no root privilege is
>> required)
>>      -a, support audio
>>      -s, enable a serial console on /dev/ttyS0
>>      -q <qemuparams> - specify custom parameters to QEMU
>>      -b <bootparams> - specify custom kernel parameters during boot
>>      -p <portnum>, tcp serial port number
>>      -B <biosdir>, bios directory
>>      -F <biosfilename>, bios filename.
>>
>>      Examples:
>>        runqemu -m qemuarm -n
>>        runqemu -m qemuarm -t ext4
>>        runqemu -m qemux86-64 -r core-image-sato -t ext4
>>        runqemu -m qemux86 -r path/to/nfsrootdir/
>>        runqemu -r path/to/deploy/dir/image/file.vmdk
>>        runqemu -m qemumips -q "-m 256"
>>        runqemu -m qemuppc -b "psplash=false"
>
> Sorry about not responding to this before now. My concerns:
>
> a) The commandline structure is changing and I'm not sure I like the
> new one or believe its an improvement. This is particularly problematic
> from a documentation perspective. Is there a way to preserve the
> existing syntax?

I did like to preserve the existing command, but the main problem is
that then we had to hardcode the MACHINE knowledge into the code,
for example, when we run:
runqemu qemux86-64 core-image-sato

The qemux86-64 should be hardcoded into the code, otherwise it
doesn't know this is a machine arg or typo.

I will think about if we can use a general database (e.g., tmp/runqemu_data)
to save MACHINE after build, then maybe we don't have to hardcode
MACHINE into the script.

>
> b) The question of python verses shell. I'm leaning towards making this
> a python script rather than shell at this point. It would mean you'd
> need python to run the scripts but we already need that for a variety
> of other tools so in general I think I prefer that. We do need to make
> sure the new python version supports what the current shell script does
> though.

This sounds good to me.

>
> c) I don't think qemu-boot should be added be hardcoded into
> image.bbclass, we need to find a better way to do this.

Sorry, I don't quite understand this, the code inside image.bbclass is:

+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot', 
'', d)}"
+inherit ${QEMU_BOOT_CLASS}

It doesn't look like a hardcode ?

>
> d) I think we need to document the new API/variables somewhere so that
> we don't just have a random ever changing set of variables but some
> kind of standard we're trying to encourage.

Sounds, good.

// Robert

>
> Cheers,
>
> Richard
>