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