qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'
Date: Fri, 14 May 2010 16:02:55 +0100
User-agent: Mutt/1.4.1i

On Fri, May 14, 2010 at 09:52:53AM -0500, Anthony Liguori wrote:
> On 05/14/2010 09:42 AM, Daniel P. Berrange wrote:
> >
> >It is preferable to query the explicit capability wanted, because
> >version numbers are useless when distros backport features,
> 
> Unless distros add their own release number to the version information 
> and libvirt learns about the features they add.

And features removed / compiled out. eg SDL removed, es1370 sound driver
removed, etc, etc. 

Version numbers are a really bad way to determine availability of
functionality. You end up having to build a giant matrix of features
vs version numbers, which will be outdated the moment its created.

If you want feature X, you need to be able to check for prescense of 
feature X, not infer it from another piece of information that is
only loosely related.

eg, if you want to use a kernel filesystem, you don't perform a check
a kernel version number, because its inevitably wrong. You check 
/proc/filesystems to see if the filesystem is supported.

> I think that's the sanest approach.  Just because a distro backports a 
> feature doesn't mean that it behaves like the upstream version.  libvirt 
> really needs to treat distro packages as separate entities from upstream 
> IMHO.

If a distro changes the semantics of a upstream feature everyone looses
no matter which way you look at it.

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]