[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
Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output
Fri, 27 Jul 2012 19:17:39 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.0.97 (gnu/linux)
"Daniel P. Berrange" <address@hidden> writes:
> 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)
I certainly don't mean to slow down the move forward. And requiring a
real use case before accepting a feature makes sense anyway.