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

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, May 14, 2010 at 09:22:55AM -0500, Anthony Liguori wrote:
> 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?

It is preferable to query the explicit capability wanted, because
version numbers are useless when distros backport features, and
when kvm is using kvm-XXX numbering that's completely unrelated
to the qemu-X.Y.Z numbering. Version numbers are the last resort
if there's no alternative way to determine the capability


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|