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

[Anthony Liguori]

On 07/22/2010 03:42 AM, Daniel P. Berrange wrote:
> On Wed, Jul 21, 2010 at 06:39:32PM -0500, Anthony Liguori wrote:
>    
> > On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
> >      
> > > > Yes there is.  Use the version number.
> > > >
> > > >          
> > > The version number is not suitable, because features can be removed at
> > > compile time and/or
> > >        
> > I don't see any features that libvirt would need to know about that are
> > disabled at compile time that aren't disabled by platform features (i.e.
> > being on a Linux vs. Windows host)
> >      
> SDL.

libvirt executes qemu from a daemon, how does SDL come into play?  Why 
do you need to probe whether it's supported anyway?  If a user requests 
SDL (I assume through /session) if it fails it fails.  Doesn't seem like 
a huge loss to me comparatively speaking.

>   vhost-net.
>    

vhost-net is unconditionally displayed in the help output regardless of 
whether the binary supports it.

You cannot assume that qemu supports vhost-net just because it says 
something in the help output.

> > >   added via patch backports.
> > >        
> > 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.

> > >   The only reliable way is
> > > to query the QEMU binary to ask it what it actually supports.
> > >
> > >        
> > And you do that by asking QEMU what it's version number is.  If the
> > version number isn't reliable because a distro backported features
> > without changing it, then the distro is broken.  It's no different than
> > if we had a capabilities system and a distro added a feature without
> > adjusting the advertises capabilities.
> >      
> Using version numbers simply isn't scalable / sustainable in the
> long term.

And parsing help output is?

I'm not claiming that version numbers is a long term solution.  But it's 
a better interim solution than parsing help output.

It's time to fix this problem properly.  There's been plenty of feedback 
that relying on help output isn't acceptable.

Regards,

Anthony Liguori