On Tue, Jul 27, 2010 at 12:20:55PM -0500, Anthony Liguori wrote: > On 07/27/2010 12:00 PM, Daniel P. Berrange wrote: > >>Yup. You'll need to decide up front if you want to probe for a feature > >>when it's introduced and have something added to capabilities. > >> > >>This is simple though. A few weeks before 0.14 is released, go through > >>the change log, and anything that looks interesting, add a cap flag. > >> > >That doesn't work for features which already exist in QEMU which are > >not yet supported in libvirt. eg consider QEMU 0.13 is released, and > >then we want to add a new feature to libvirt a month later. > > Right. So sit down and look at the 0.13 changelog and if there's any > features that you think you might want to support at some point in time, > add a capability.
Not really practical - pretty much anything is a candidate because we want to support as many of QEMU features as possible. > >It offers significantly less information that the existing -help > >data, so I don't think it is workable as a replacement. We'd get > >into the bad situation where we could support a feature in 0.12 > >but not in 0.13, unless we went back to using -help output again. > > > >If we're going for a short term hack, then how about a combination > >of > > > >http://www.mail-archive.com/qemu-devel@nongnu.org/msg34944.html > >http://www.mail-archive.com/qemu-devel@nongnu.org/msg34960.html > > > > Would have failed in exactly the same way that the current -help parsing > fails. The description of an argument in the help text is not a > capabilities string. This particular case of cache modes might have failed, but in the broader picture it would have been more reliable. The vasty majority of the time, we only check whether a particular named argument exists. This patch would make it very reliable todo so because you could simply extract a single named field from the JSON doc. The cases where we looked at the parameter options would have been improved a little, but still be potentially fragile. Checking for version number would also be improved. So overall while obviously not perfect, it would be significantly better than the solution today and using an approach that isn't a complete throwaway solution. Regards, 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 :|
