[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 14:19:18 +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:
>> 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.
>> Some users might prefer to get this via a command line option rather
>> than a QMP command. They should ask for it.
> In my original proposal from 2 years back, I actually exposed a number
> of QMP query-XXX commands via a -capabilities XXXX command line args.
> On revisiting it though, I think that since we'll want to ask for
> info on many different aspects, it is easier just to use QMP directly
> rather than string together various command line args upfront, or
> invoke QEMU multiple times.
I read that as "libvirt isn't asking for it". That's fine. Whoever
wants it needs to ask.