[libvirt] [PATCH 0/7] Drop support for QEMU < 0.12.0
Daniel P. Berrange
berrange at redhat.com
Fri Nov 6 10:07:47 UTC 2015
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 :|
More information about the libvir-list
mailing list