[OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it
Robert Yang
liezhi.yang at windriver.com
Thu Jun 23 08:43:00 UTC 2016
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
>
More information about the Openembedded-core
mailing list