[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: |
Thu, 26 Jul 2012 13:47:23 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
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.
Regards,
Daniel
--
|: 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 :|