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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list