On 07/28/2010 04:53 AM, Daniel P. Berrange wrote:
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.
I'd be willing to spit out the option names minus the help
descriptions. The option names are part of a supported interface so
there's no harm in exposing an interface for that.
But I think libvirt really needs option names + indication when we've
added parameters to an option, right?
Regards,
Anthony Liguori
Regards,
Daniel
