From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Bruce Rogers <brogers@novell.com>
Subject: Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Date: Thu, 22 Jul 2010 09:42:25 +0100 [thread overview]
Message-ID: <20100722084225.GA1524@redhat.com> (raw)
In-Reply-To: <4C478534.2020106@codemonkey.ws>
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 :|
next prev parent reply other threads:[~2010-07-22 8:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 20:32 [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help Bruce Rogers
2010-07-21 20:55 ` Anthony Liguori
2010-07-21 21:32 ` Daniel P. Berrange
2010-07-21 21:45 ` Anthony Liguori
2010-07-21 21:58 ` Daniel P. Berrange
2010-07-21 23:39 ` Anthony Liguori
2010-07-22 0:45 ` Jamie Lokier
2010-07-22 6:53 ` Markus Armbruster
2010-07-22 8:42 ` Daniel P. Berrange [this message]
2010-07-22 14:19 ` Anthony Liguori
2010-07-23 8:00 ` Markus Armbruster
2010-07-26 15:53 ` Anthony Liguori
2010-07-26 16:26 ` Avi Kivity
2010-07-26 16:29 ` Avi Kivity
2010-07-26 19:03 ` Anthony Liguori
2010-07-26 19:24 ` Avi Kivity
2010-07-26 19:43 ` [Qemu-devel] " Juan Quintela
2010-07-26 16:40 ` [Qemu-devel] " Anthony Liguori
2010-07-26 16:54 ` Avi Kivity
2010-07-26 18:59 ` Anthony Liguori
2010-07-26 19:19 ` Avi Kivity
2010-07-26 19:35 ` Anthony Liguori
2010-07-26 19:43 ` Avi Kivity
2010-07-26 20:03 ` Anthony Liguori
2010-07-27 8:11 ` Markus Armbruster
2010-07-27 9:47 ` Jes Sorensen
2010-07-27 12:30 ` Cole Robinson
2010-07-27 12:50 ` Anthony Liguori
2010-07-27 13:35 ` Cole Robinson
2010-07-27 8:26 ` Markus Armbruster
2010-08-03 9:43 ` Richard W.M. Jones
2010-07-27 8:56 ` Kevin Wolf
2010-07-22 13:45 ` Luiz Capitulino
2010-07-27 10:26 ` Daniel P. Berrange
2010-07-27 13:11 ` Bruce Rogers
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=20100722084225.GA1524@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=brogers@novell.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.