Re: [libvirt] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output

[adding libvirt] On 07/25/2012 01:47 PM, Anthony Liguori wrote: 0.13? How long have you been sitting on this commit? :) We've gone a long way with things like newer libvirt requiring QMP, and being able to use query-commands and even 'qemu -device ?' to figure out which devices are present, which is already more reliable than parsing -help output. There may still be a few things to fix (for example, I already pointed out that libvirt 0.9.13 is bogus for refusing to even attempt 'qemu -device,?' unless it guesses from '-help' output that it will work; it would be better to just attempt it in the first place and deal with the fallout), but it should be easy to fix in time for libvirt 0.10.0, and certainly coordinate things so that new enough libvirt comes out close to the time of qemu 1.2. This is the part I'm most worried about - it says that any time libvirt decides to flag a new capability that it cares about within qemu, then both libvirt and qemu have to be upgraded in lockstep to coordinate the use of that capability. The problem is that sometimes libvirt doesn't care about a capability until after qemu has already been released (for example, we didn't realize the power of fd: migration until several releases after qemu had first implemented it, at which point when we added the capability bit, we were able to retroactively detect it for several qemu versions by parsing -help). ... Already incomplete. For example, libvirt has recently added block-job-sync, block-job-async, scsi-cd, and several others. Thankfully, these days most of the new feature bits being added in libvirt's qemu_capabilities.h are related to things that were probed from 'qemu -device ?' or from QMP 'query-commands', and not from something additionally scraped from '-help' for the first time. I had to go back to libvirt commit 63b4243 (May 15) to find a capability that libvirt learned by scraping -help output (namely, support for -no-user-config). But yet this is one of the important config bits that libvirt really needs to know, and not one that can easily be learned from machine-parseable '-device ?' I'm worried that an interface like this will let libvirt know about the existing features that libvirt is trying to use, but will hurt the ability of adding new feature detection in to libvirt (basically, a newer libvirt wouldn't be able to retroactively take advantage of an older feature already present in older qemu without parsing some back-channel, at which point what good was having this libvirt-specific channel?). There's also another problem if we decide to keep this file synced across projects: Libvirt is LGPLv2+. You can obviously upgrade to GPLv2+ as part of importing the code from libvirt to qemu; but if you decide that a new feature is worth adding a bit to this file, then libvirt can't do the reverse sync unless you relax the license of this file. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org