Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help

[Avi Kivity <avi@redhat.com>]

  On 07/26/2010 06:53 PM, Anthony Liguori wrote:
>> You almost sound like Dan refused to consider anything but parsing help
>> output, like it were Dan's fault that QEMU still doesn't provide a
>> usable interface for querying its capabilities, and like the way to get
>> it was to put more pressure on Dan.
>
> I'm not blaming anyone.  As I see it, we have a supported interface 
> for determining which interfaces are supported by a given version of 
> QEMU--the version number.  If the version number is not reliable 
> because downstreams backport features in an undetectable way, that is 
> not our (upstream) problem.
>
> I'm a practical guy, and I don't see that it's a huge burden for 
> libvirt to detect downstreams and build a feature matrix based on 
> versions.  If someone demonstrates that it's infeasible, I'll happily 
> reconsider.

It generates a dependency.  If the downstream backports feature A in 
version V, then a new version of libvirt needs to be issued which has 
(A, V) in its feature matrix.

On the other hand, capability reporting, even if suckily implemented via 
-help, doesn't need new versions of libvirt.

>> That would be unfair.  Dan posted patches to fix this problem properly,
>> which puts the ball squarely in our court.
>
> The patches are a good step, but they don't solve the problem.  There 
> will always be older versions of libvirt and older versions of QEMU so 
> what's libvirt going to do with those?

Is there a released version of qemu which breaks libvirt?

Older versions of libvirt aren't a problem, they simply don't know about 
cache=unsafe.

>
>>    Could we please refrain from
>> gratuitously fscking up libvirt just a bit longer, until we finish
>> improving and merging Dan's patches?
>
> Even without doing version based feature detection, libvirt could just 
> do a better job of parsing the help output.

True.  However, we don't provide a sane interface for detecting qemu 
capabilties, so there's no need to act surprised when users don't 
implement perfect work arounds.

> The help output is *not* a supported interface. 

There is no supported, usable interface for this.

> There are very simple changes libvirt can and should make.  The fix to 
> this "problem" belongs in libvirt, no QEMU.

libvirt can't make retroactive changes.  Sure, it can issue an update, 
but if we can help them avoid it by changing the order of the help text, 
I don't see why we can't do that.

-- 
error compiling committee.c: too many arguments to function