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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core