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

[Anthony Liguori <anthony@codemonkey.ws>]

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