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

[Anthony Liguori]

On 07/23/2010 03:00 AM, Markus Armbruster wrote:
> Anthony Liguori<address@hidden>  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

> [...]
>