"Daniel P. Berrange" <berra...@redhat.com> writes: > On Fri, Jul 27, 2012 at 01:23:03PM +0200, Markus Armbruster wrote: >> "Daniel P. Berrange" <berra...@redhat.com> writes: >> > 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. > > I think you are quite possibly correct, but for the sake of enabling > us to move forward without more arguments, my inclination is to ignore > this just now :-) Lets get the new commands Anthony posted merged, and > port libvirt to use this new approach. Once that's all done, we can > evaluate whether there is a any more information we ought to provide > which might require a query-cmdline-options, or something else more > targetted (eg query-chardev-options or something)
I certainly don't mean to slow down the move forward. And requiring a real use case before accepting a feature makes sense anyway.