[OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it
Richard Purdie
richard.purdie at linuxfoundation.org
Thu Jun 23 08:17:15 UTC 2016
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?
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.
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.
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.
Cheers,
Richard
More information about the Openembedded-core
mailing list