All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>,
	clalance@redhat.com, qemu-devel@nongnu.org,
	Cole Robinson <crobinso@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'
Date: Fri, 14 May 2010 10:08:25 -0500	[thread overview]
Message-ID: <4BED6769.1010608@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100514150255.GN9282@redhat.com>

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	other threads:[~2010-05-14 15:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-12 20:29 [Qemu-devel] [PATCH] Revive -version 'QEMU PC Emulator...' Cole Robinson
2010-05-12 20:38 ` [Qemu-devel] " Jes Sorensen
2010-05-12 20:48   ` Cole Robinson
2010-05-13  8:35     ` Jes Sorensen
2010-05-13 13:04       ` Cole Robinson
2010-05-13 13:07         ` Jes Sorensen
2010-05-13 13:21           ` Daniel P. Berrange
2010-05-13 13:38             ` Luiz Capitulino
2010-05-13 14:00             ` Paul Brook
2010-05-13 19:20               ` Blue Swirl
2010-05-13 21:24                 ` Stuart Brady
2010-05-14 13:24           ` Anthony Liguori
2010-05-14 13:54             ` Daniel P. Berrange
2010-05-14 14:22               ` Anthony Liguori
2010-05-14 14:42                 ` Daniel P. Berrange
2010-05-14 14:52                   ` Anthony Liguori
2010-05-14 15:02                     ` Daniel P. Berrange
2010-05-14 15:08                       ` Anthony Liguori [this message]
2010-05-14 13:17     ` Anthony Liguori
2010-05-14 13:25       ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BED6769.1010608@linux.vnet.ibm.com \
    --to=aliguori@linux.vnet.ibm.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clalance@redhat.com \
    --cc=crobinso@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.