"Daniel P. Berrange" <berra...@redhat.com> 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!