On 07/27/2010 08:50 AM, Anthony Liguori wrote: > On 07/27/2010 07:30 AM, Cole Robinson wrote: >> On 07/27/2010 05:47 AM, Jes Sorensen wrote: >> >>> On 07/27/10 10:11, Markus Armbruster wrote: >>> >>>> Anthony Liguori<anth...@codemonkey.ws> writes: >>>> >>>>> On 07/26/2010 02:19 PM, Avi Kivity wrote: >>>>> >>>>>> We should try to support all users, prioritized by the number of end >>>>>> users they represent. If this patch broke some other large user >>>>>> we'd be in a bind. But likely this isn't the case so we aren't. >>>>>> >>>>> As I've said, I'm pragmatic and that's why I've argued for these >>>>> changes in the past. But libvirt should have changed a long time ago >>>>> to using something more reliable (like version). >>>>> >>>> You want pragmatic? I can give you pragmatic! We apply the trivial >>>> patch that helps libvirt and hurts nobody, and save our breath& typing >>>> for designing and implementing a capability system. >>>> >>> To be honest, this is exactly the same problem we had when the output >>> from -version changed and libvirt broke because it did static string >>> parsing instead of doing it properly. Back then the output of -version >>> was changed back to accommodate libvirt, but I am not aware that libvirt >>> went ahead and fixed the real problem in the mean time. >>> >>> >> The output of -version was not changed back, the revert was rejected. >> (Meaning QEMU has no stable interface for determining version info. >> > > Actually, we do. 'info version' in the monitor returns just the version. >
My bad, I didn't know about that. Then again, having to start up a qemu instance and connect to the monitor just to get a bare version string seems overkill. > Additionally, -version on the command line spits out just a single > version string. > I wouldn't really call that 'stable', figuring that the output was changed recently. > The trouble libvirt has is that it's parsing the help output and needs > to use a string to identify which line is the version (due to the way > it's parsing the output). > > Notice a theme here? > A few: libvirt's -help parsing is fragile. Libvirt is using an unsupported/unstable capabilities system, though it works acceptably in practice. Some others: Libvirt is a significant qemu consumer and provides value to the qemu project. qemu lacks a supported discoverable capabilities interface. And some facts: qemu 0.13 will not work with 95% of existing libvirt deployments. The 2 requested qemu reverts will have approx. 0 functional impact on plain qemu users. Can we evaluate these all together? Really, what's the harm in reverting these changes for 0.13, reapplying after the release is cut, and making a commitment to get some capabilities interface into 0.14? (and no libvirt appeasing -help/-version patches in the 0.14 cycle) - Cole
