"Daniel P. Berrange" <berra...@redhat.com> writes: > On Thu, Jul 26, 2012 at 01:47:23PM +0100, Daniel P. Berrange wrote: >> 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. > > Oh, if it is possible to get this data via QOM commands already, > or it can be easily made to work with QOM commands, then obviously > I wouldn't ask for these new query-XXX commands.
Yup. You could do: qom-list-types implements=TYPE_DEVICE And that will give you the various types. We'll need to add a: device-list-properties typename=FOO I've got a patch locally for that that I'm testing right now. Paolo and I never came to an agreement on how to do this generically for Objects but I'm happy with a device-specific interface for the short term. Regards, Anthony Liguori > > 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 :|