qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Date: Thu, 22 Jul 2010 09:42:25 +0100
User-agent: Mutt/1.4.1i

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. vhost-net.

> >  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.
 
> >  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. Imagine trying to maintain a list of kernel version
numbers where 'ext4' was available, instead of just looking at
/proc/filesystems for the declared capabilities of the kernel
No sane app would do this kind of thing with version numbers
because they will always be outdated and always wrong if the 
user decides to compile out certain features. The only thing
version numbers are good for is in bug reporting to indicate
the build being used to the vendor.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]