[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output |
Date: |
Fri, 27 Jul 2012 13:23:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.97 (gnu/linux) |
"Daniel P. Berrange" <address@hidden> writes:
> On Wed, Jul 25, 2012 at 02:47:57PM -0500, Anthony Liguori wrote:
>> The help output is going to change dramatically for 0.13. We've
>> spent too long
>> waiting for a perfect solution to capabilities handling and the end loser is
>> the direct consumer of QEMU because the help output is awful.
>>
>> I will not apply any patches that change help output until 0.13 development
>> opens up. This should give libvirt adequate time to implement support for
>> dealing with this new option.
>
> I completely agree with this. We have spent far too long making do with
> "help output" and its about time we finish with this once & for all.
> I'm assuming you mean the 1.3 release here. If so I'll agree that it
> is an acceptable plan to change help output at the start of the 1.3
> release.
>
> This gives us enough time to agree on what todo to support apps needing
> to query QEMU.
>
>> This capabilities set comes directly from libvirt's source code so
>> it's entirely
>> adequate for libvirt's purposes. We can still explore more sophisticated
>> approaches that are more general purpose but the help output will be
>> changing.
>
> While I appreciate what you're trying todo here, I think this would be a
> serious mistake on many counts, and even be incorrect in some ways.
>
> - It ignores the needs of other apps using QEMU. In particular Richard
> Jones has frequently requested a way to detect QEMU capabilities
> to satisfy libguestfs. I think it is unreasonable to expect libguestfs
> to use the libvirt capabilities described here. Likewise other apps
>
> - This is just a point in time snapshot of what libvirt currently uses
> from QEMU. If, for example, someone provided a patch to libvirt to
> support the bluetooth devices we'd be stuck, because although QEMU
> already supports bluetooth, this is not expressed in any of the
> caps libvirt already has.
>
> - Not all of this information actually comes from the help output.
> A bunch of it is stuff we detect from '-device ?' and
> '-device name,?'. Although, (AFAIR) no one has objections to use
> parsing the -device output because it is much better defined &
> stable than -help, I think we could use some improvement to make
> the parsing 100% long term maintainable by QEMU/apps. Similarly
> we do '-cpu ?' and '-machine ?'. Some of the caps are set based
> on the machine architecture, or QEMU version.
>
> - Some of the caps are set based on what libvirt is actually
> able to handle from a command line generation POV, so having
> QEMU report these unconditionally is misleading/wrong. It is
> not about what QEMU supports, it is about what libvirt is able
> to cope with.
>
> - In the future some of the caps may be describing supported
> monitor commands, detected via 'query-commands' QMP cmd.
>
> - Users of libvirt are asking us to expose information about
> what QEMU supports, in particular wrt to devices, but also
> other aspects of configuration.
>
>
>
> A long time back I proposed a '-capabilities' command line argument
> for querying QEMU.
>
> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00921.html
>
> There was a long discussion about this & many aspects of it were
> disliked. In retrospect I agree with many of the comments, and
> am glad we didn't adopt this. I think, however, there is a merit
> in trying something vaguely related again, but with some key
> differences. Basically I'd sum up my new idea as "just use QMP".
>
>
> * No new command line arguments like -capabilities
>
> * libvirt invokes something like
>
> $QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
>
> * libvirt then runs a number of QMP commands to find out
> what it needs to know. I'd expect the following existing
> commands would be used
>
> - query-version - already supported
> - query-commands - already supported
> - query-events - already supported
> - query-kvm - already supported
> - qom-{list,list-types,get} - already supported
> - query-spice/vnc - already supported
>
> And add the following new commands
>
> - query-devices - new, -device ?, and/or -device NAME,? data
> in QMP
> - query-machines - new, -M ? in QMP
> - query-cpu-types - new, -cpu ? in QMP
>
> 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.
Some users might prefer to get this via a command line option rather
than a QMP command. They should ask for it.
> So in summary, as of 1.2 QEMU, libvirt would
>
> - Remove all use of -help, and other -XXXX command line args
> for detecting capabilities
>
> - Use -qmp and issue commands above to detect whatever it
> can
>
> - Any other existing capabilities are just "enable by default"
> for QEMU >= 1.2
>
> - Detect future stuff via existing monitor commands, otherwise
> just do it by QEMU version number.
>
>
> So in terms of QEMU work, all I'm asking is to be allowed to
> implement the query-devices, query-machines & query-cpu-types
> QMP monitor commands. I'll happily do this work myself, if it
> brings an end to the -help madness.
Sounds like a plan!