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: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'
Date: Fri, 14 May 2010 10:08:25 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/14/2010 10:02 AM, Daniel P. Berrange wrote:
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.

You need version numbers to understand behavior. If you also want to know compile settings, we need the equivalent of /proc/config (a simple -build-config command could output our build config).

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.

You assume that feature X is idempotent across multiple downstreams. That's not a realistic assumption IMHO.

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.

And we have this today with QMP. It provides a mechanism to query capabilities. Fundamentally, this is a bootstrap problem and the best way to bootstrap is with a version number.

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.

It's a reality so we have to deal with it.

Regards,

Anthony Liguori

Daniel




reply via email to

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