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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/23/2010 03:00 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>    
>> On 07/22/2010 03:42 AM, Daniel P. Berrange wrote:
>>      
>>> On Wed, Jul 21, 2010 at 06:39:32PM -0500, Anthony Liguori wrote:
>>>        
> [...]
>    
>>>> If a distro backports a feature, it should change the QEMU version
>>>> string.  If it doesn't, that's a distro problem.
>>>>
>>>>          
>>> This puts you in the position of having to maintain an ever changing
>>> giant compatability table between version numbers and features, which
>>> just results in madness.
>>>
>>>        
>> Or working with QEMU to have a better solution.
>>
>> We've been complaining for a long time about parsing help output and
>> we've made changes as "temporary" stop gaps for libvirt too many times
>> in the past.
>>
>> This problem needs to get fixed properly.
>>      
> 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.

> 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?

>    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.

The help output is *not* a supported interface.  There are very simple 
changes libvirt can and should make.  The fix to this "problem" belongs 
in libvirt, no QEMU.

Regards,

Anthony Liguori

> [...]
>