Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 05/14/2010 08:54 AM, Daniel P. Berrange wrote:
> On Fri, May 14, 2010 at 08:24:09AM -0500, Anthony Liguori wrote:
>    
>> On 05/13/2010 08:07 AM, Jes Sorensen wrote:
>>      
>>> On 05/13/10 15:04, Cole Robinson wrote:
>>>
>>>        
>>>> On 05/13/2010 04:35 AM, Jes Sorensen wrote:
>>>>
>>>>          
>>>>> On 05/12/10 22:48, Cole Robinson wrote:
>>>>> I think rather than 1, it would be better to add a patch to libvirt to
>>>>> catch both formats. I know Chris Lalancette already cooked up a patch
>>>>> for this. Combined with the 2) patch I just posted, and 3) I think that
>>>>> should take care of the problems.
>>>>>
>>>>>            
>>>> It doesn't solve the problem for existing libvirt installations. It's
>>>> not uncommon for users to track just the latest kvm releases without
>>>> upgrading libvirt: any future qemu or kvm release will break every
>>>> version of libvirt that exists today. Given that unfortunate case, I
>>>> still recommend reverting the 'PC' change at least for long enough for a
>>>> few fixed libvirt releases to make it into the wild.
>>>>
>>>>          
>>> But that is no different from what we have today. Users who update their
>>> qemu and see issues with libvirt can also be asked to update libvirt. I
>>> have already had several cases where I needed to do that anyway.
>>>
>>> I don't like reverting a change like this, just to schedule it to be
>>> reapplied again later.
>>>
>>>        
>> The problem is, we've been down this road many times before.  Every
>> time, the libvirt folks say they just need this one change for
>> compatibility and keep on using the help output.  I understand that
>> that's the easiest thing to do so we need to make it easier for them to
>> do the right thing (which probably means making it harder to do the
>> wrong thing :-)).
>>
>> So I'm willing to apply this patch but only as part of a larger series
>> that eliminates the need for libvirt to parse help output.  The
>> important question is then, what information is libvirt getting from the
>> help output today.
>>      
> The short answer is we extract:
>
>   - QEMU version number
>   - KVM version number (if present)
>   - Probe for specific named arguments (-drive, -chardev, -device,
>     and many many more)
>    

This can be tied to version number, no?

>   - Probe for named flags (eg cache= option to -drive which appeared
>     after the initial -drive arg did)
>    

Again, this ought to be able to be tied to version number, no?

Regards,

Anthony Liguori

> Things we use the QEMU/KVM version number for:
>
>   - Track changes in syntax of an existing arg. eg -vnc changed
>     syntax between 0.8.x and 0.9.0
>   - Determine if we can use VNET_HDR flag
>   - Which migration protocols are available (tcp, unix, exec, fd)
>   - Whether we can use JSON mode monitor yet
>   - Override use of -netdev - even though its detected in -help
>     output for 0.12, we can't use it since there was no equivalent
>     netdev_add command for hotplug. So we have to blacklist it till
>     0.13
>
> In the ideal world we'd never do anything based off version number,
> everything would have some clear functional capability that could
> be queried. We'd then only need to use version to blacklist features
> we detect, but can't use for some reason.
>
> If you want the gory details, the key method is qemudComputeCmdFlag()
> in source code at line 1124:
>
>    http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_conf.c;h=5fa8c0aa1867e1f67153d72c5b37ba09157c968e;hb=HEAD
>
> This is where we detect each feature we care about in -help output
>
>
> Regards,
> Daniel
>