On Thu, Nov 05, 2015 at 06:15:52PM -0500, John Ferlan wrote:
On 11/05/2015 12:33 PM, Daniel P. Berrange wrote:
The patches for introducing virtlogd will be significantly simplified if we don't need to worry about parsing stderr during startup. This is required prior to QEMU 0.11 so that we can get the dyanamically allocated /dev/pty/NNN paths.
The QEMU 0.12.1 release was shipped in RHEL-6 vintage distros and is already quite old, so seems like a fair target version to aim for as the minimum required.
By dropping support for anything older than QEMU 0.12.0 we can remove the code for parsing stderr. The QEMU 0.12.0 release was quite special because it was the release where QEMU switched what I call its "modern" approach to configuration via -device. A major part of the complexity of the QEMU command line generator is due to need to support non-device syntax, so by mandating QEMU 0.12.0 we'll be able to kill off alot of conditional code. This series makes a start by assuming existance of 5 features, -vnc, 'info chardev', -no-reboot, -drive and -name, but there are a tonne more we can assume.
Gone through them all - in waves... first coverity, the w/ check and syntax-check builds.. and finally at least through the code looking for anything I can spot. Only had a couple of questions, mostly formatting issues found.
Urgh, sorry about all the syntax-check stuff - I completely forgot to run it before posting last night.
Beyond the questions already asked - should we version bump too? After/with patch 1? Seems this is a fairly significant change... If Erik gets the virt-admin patches in that'd version bump anyway.
Yep, its probably the kind of thing that justifies a version bump
I also assume your contention is "someone" could go through the following caps and start making similar adjustments? Although based on reading - should QEMU_CAPS_DEVICE be in the list?
I'll probably do more fixes for the following caps myself, until I end up gouging my eyes out after fixing one too many of the test suite XML files, and then leave the rest for other motiviated people :-) The CAPS_DEVICE stuff needs more investigation because of the issues I recall with non-x86 platform support. It might be that we can just say that non-x86 support requires an even newer QEMU on the basis that we never had good non-x86 support until relatively recently.
Looking at tests/qemuhelptest, we can drop about 30 capability flag tests
QEMU_CAPS_UUID, QEMU_CAPS_MIGRATE_QEMU_TCP, QEMU_CAPS_MIGRATE_QEMU_EXEC, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT, QEMU_CAPS_DRIVE_SERIAL, QEMU_CAPS_DRIVE_READONLY, QEMU_CAPS_VGA, QEMU_CAPS_0_10, QEMU_CAPS_ENABLE_KVM, QEMU_CAPS_SDL, QEMU_CAPS_XEN_DOMID, QEMU_CAPS_MIGRATE_QEMU_UNIX, QEMU_CAPS_CHARDEV, QEMU_CAPS_BALLOON, QEMU_CAPS_DEVICE, QEMU_CAPS_SMP_TOPOLOGY, QEMU_CAPS_RTC, QEMU_CAPS_NO_HPET, QEMU_CAPS_BOOT_MENU, QEMU_CAPS_NAME_PROCESS, QEMU_CAPS_SMBIOS_TYPE, QEMU_CAPS_VGA_NONE, QEMU_CAPS_MIGRATE_QEMU_FD, QEMU_CAPS_DRIVE_AIO, QEMU_CAPS_NO_SHUTDOWN, QEMU_CAPS_PCI_ROMBAR, QEMU_CAPS_NO_ACPI, QEMU_CAPS_VIRTIO_BLK_SG_IO, QEMU_CAPS_CPU_HOST, QEMU_CAPS_VNC
The only slow complication is that some non-x86 architectures were slow in converting to -device syntax, so we cannot entirely assume -device is used everywhere.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|