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