Re: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/28/2010 04:53 AM, Daniel P. Berrange wrote:
> On Tue, Jul 27, 2010 at 12:20:55PM -0500, Anthony Liguori wrote:
>    
>> On 07/27/2010 12:00 PM, Daniel P. Berrange wrote:
>>      
>>>> Yup.  You'll need to decide up front if you want to probe for a feature
>>>> when it's introduced and have something added to capabilities.
>>>>
>>>> This is simple though.  A few weeks before 0.14 is released, go through
>>>> the change log, and anything that looks interesting, add a cap flag.
>>>>
>>>>          
>>> That doesn't work for features which already exist in QEMU which are
>>> not yet supported in libvirt. eg consider QEMU 0.13 is released, and
>>> then we want to add a new feature to libvirt a month later.
>>>        
>> Right.  So sit down and look at the 0.13 changelog and if there's any
>> features that you think you might want to support at some point in time,
>> add a capability.
>>      
> Not really practical - pretty much anything is a candidate because
> we want to support as many of QEMU features as possible.
>
>    
>>> It offers significantly less information that the existing -help
>>> data, so I don't think it is workable as a replacement. We'd get
>>> into the bad situation where we could support a feature in 0.12
>>> but not in 0.13, unless we went back to using -help output again.
>>>
>>> If we're going for a short term hack, then how about a combination
>>> of
>>>
>>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34944.html
>>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34960.html
>>>
>>>        
>> Would have failed in exactly the same way that the current -help parsing
>> fails.  The description of an argument in the help text is not a
>> capabilities string.
>>      
> This particular case of cache modes might have failed, but in the
> broader picture it would have been more reliable. The vasty
> majority of the time, we only check whether a particular named
> argument exists. This patch would make it very reliable todo so
> because you could simply extract a single named field from the
> JSON doc. The cases where we looked at the parameter options
> would have been improved a little, but still be potentially fragile.
> Checking for version number would also be improved. So overall
> while obviously not perfect, it would be significantly better than
> the solution today and using an approach that isn't a complete
> throwaway solution.
>    

I'd be willing to spit out the option names minus the help 
descriptions.  The option names are part of a supported interface so 
there's no harm in exposing an interface for that.

But I think libvirt really needs option names + indication when we've 
added parameters to an option, right?

Regards,

Anthony Liguori

> Regards,
> Daniel
>