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

[Cole Robinson <crobinso@redhat.com>]

On 07/27/2010 08:50 AM, Anthony Liguori wrote:
> On 07/27/2010 07:30 AM, Cole Robinson wrote:
>> On 07/27/2010 05:47 AM, Jes Sorensen wrote:
>>    
>>> On 07/27/10 10:11, Markus Armbruster wrote:
>>>      
>>>> Anthony Liguori<anthony@codemonkey.ws>  writes:
>>>>        
>>>>> On 07/26/2010 02:19 PM, Avi Kivity wrote:
>>>>>          
>>>>>> We should try to support all users, prioritized by the number of end
>>>>>> users they represent.  If this patch broke some other large user
>>>>>> we'd be in a bind.  But likely this isn't the case so we aren't.
>>>>>>            
>>>>> As I've said, I'm pragmatic and that's why I've argued for these
>>>>> changes in the past.  But libvirt should have changed a long time ago
>>>>> to using something more reliable (like version).
>>>>>          
>>>> You want pragmatic?  I can give you pragmatic!  We apply the trivial
>>>> patch that helps libvirt and hurts nobody, and save our breath&  typing
>>>> for designing and implementing a capability system.
>>>>        
>>> To be honest, this is exactly the same problem we had when the output
>>> from -version changed and libvirt broke because it did static string
>>> parsing instead of doing it properly. Back then the output of -version
>>> was changed back to accommodate libvirt, but I am not aware that libvirt
>>> went ahead and fixed the real problem in the mean time.
>>>
>>>      
>> The output of -version was not changed back, the revert was rejected.
>> (Meaning QEMU has no stable interface for determining version info.
>>    
> 
> Actually, we do.  'info version' in the monitor returns just the version.
> 

My bad, I didn't know about that. Then again, having to start up a qemu
instance and connect to the monitor just to get a bare version string
seems overkill.

> Additionally, -version on the command line spits out just a single 
> version string.
> 

I wouldn't really call that 'stable', figuring that the output was
changed recently.

> The trouble libvirt has is that it's parsing the help output and needs 
> to use a string to identify which line is the version (due to the way 
> it's parsing the output).
> 
> Notice a theme here?
> 

A few: libvirt's -help parsing is fragile. Libvirt is using an
unsupported/unstable capabilities system, though it works acceptably in
practice.

Some others: Libvirt is a significant qemu consumer and provides value
to the qemu project. qemu lacks a supported discoverable capabilities
interface.

And some facts: qemu 0.13 will not work with 95% of existing libvirt
deployments. The 2 requested qemu reverts will have approx. 0 functional
impact on plain qemu users.

Can we evaluate these all together? Really, what's the harm in reverting
these changes for 0.13, reapplying after the release is cut, and making
a commitment to get some capabilities interface into 0.14? (and no
libvirt appeasing -help/-version patches in the 0.14 cycle)

- Cole