[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to sto

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output
Date: Fri, 27 Jul 2012 17:35:28 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jul 27, 2012 at 01:23:03PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <address@hidden> writes:
> > The above would take care of probably 50% of the current libvirt
> > capabilities probing, including a portion of the -help stuff. Then
> > there is all the rest of the crap we detect from the -help. We could
> > just take the view, that "as of 1.2", we assume everything we previously
> > detected is just available by default, and thus don't need to probe
> > it.  For stuff that is QOM based, I expect we'll be able to detect new
> > features in the future using the qom-XXX monitor commands. For stuff
> > that is non-qdev, and non-qom, libvirt can just do a plain version
> > number check, unless we decide there is specific info worth exposing
> > via other new 'query-XXX' monitor commands.
> Assuming version X (according to query-version) supports no less than
> upstream version X sounds fair.
> If a command line option has a corresponding QMP command, probing QMP
> for the feature suffices.  For instance, query-devices gives you devices
> for -device.
> I'm afraid there could still be an occasional need for probing the
> command line.  A simple, machine-readable command line self-description
> could satisfy it.  Something like:
> - query-cmdline-options: JSON representation of qemu_options[], with
>   unnecessary detail elided.  Basically option name and whether it takes
>   an argument.
> For options with a QemuOpts argument, we may want to add argument
> self-description.  Basically its QemuOptsList, with unnecessary detail
> elided.  Non-QemuOpts arguments don't get that.  New structured option
> arguments should use QemuOpts anyway.

I think you are quite possibly correct, but for the sake of enabling
us to move forward without more arguments, my inclination is to ignore
this just now :-) Lets get the new commands Anthony posted merged, and
port libvirt to use this new approach. Once that's all done, we can
evaluate whether there is a any more information we ought to provide
which might require a query-cmdline-options, or something else more
targetted (eg query-chardev-options or something)

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]