Re: [libvirt] [Qemu-devel] [PATCH v4 2/2] query-command-line-options: query all the options in qemu-options.hx

On 03/07/2014 02:54 AM, Markus Armbruster wrote: I don't buy that. '-cdrom filename' could easily be re-written [in a future qemu version] to use QemuOpts with an implied parameter name (we've done that elsewhere, such as for '-machine'). In other words, I think we could make it become shorthand for '-cdrom file=filename', at which point the QemuOpts spelling is available and would now show up as "parameters":[{"name":"file"...}]. Thus, in converting -cdrom to QemuOpts, we can still maintain command-line back-compat, while making the query-command-line-options output more featureful. In other words, _for now_ it takes unspecified parameters, and the fact that it is only a single parameter in the form 'filename' rather than a more typical parameter 'file=filename' is not a show-stopper. So your idea of a tri-state (QemuOpts, no argument, or other argument) doesn't add anything - any option that takes "other argument" could be converted to take QemuOpts, and from the command line, we can't tell the difference from whether something was implemented by QemuOpts, only by whether we have introspection on what the argument consists of. Meanwhile, it DOES point out that our use of implicit argument in QemuOpts ought to be exposed to the introspection mechanism, for introspection to be fully descriptive. That is, maybe we should modify our introspection to add a new 'implied-name': ## # @CommandLineParameterInfo: # ... # @implied-name: #optional, if present and true, the parameter can be # specified as '-option value' instead of the preferred # spelling of '-option name=value' (since 2.0) # Since 1.5 { 'type': 'CommandLineParameterInfo', 'data': { 'name': 'str', 'type': 'CommandLineParameterType', '*help': 'str', '*implied-name': 'bool' } } This part is still true. When parameters[] is non-empty, it is a QemuOpts and we know all recognized parameters (well, more precisely, the subset of QemuOpts that were explicitly called out - given your point 2 about the mess of -drive); when it is empty, then all we know is whether the argument is a boolean or takes unspecified arguments (where the conversion of those unknown arguments to QemuOpts will be what finally lets us introspect the format of those unknown arguments). We already know 'query-command-line-options' is not a full introspection yet. So far, libvirt has managed to get by on partial information (in fact, the whole hack for special-casing -drive to merge multiple lists together was precisely to avoid a regression with at least providing the partial information that libvirt was actually using). Documenting that QemuOpts information may be incomplete may be nice, but shouldn't hold up the initial purpose of this patch which is to document non-QemuOpts options. And knowing that an option takes unspecified arguments is still better than not knowing about the option at all. Ouch. I did not realize they were ABI. 'query-command-line-options' should expose the command line spelling, but maybe that argues that we need to enhance our QAPI introspection to make it easier to document the special cases: ## # @CommandLineOptionInfo: ... # @config-name: #optional if present, the command line spelling differs # from the name used by -readconfig (since 2.0) # Since 1.5 ## { 'type': 'CommandLineOptionInfo', 'data': { 'option': 'str', '*config-name':'str', 'parameters': ['CommandLineParameterInfo'] } } and where we would expose: {"parameters": [], "option": "acpitable", "config-name": "acpi", "argument": true}, or even combining my above suggestions: {"option":"M", "parameters":[], "config-name":"machine", "argument": true}, {"option":"machine", "parameters":[ {"name": "firmware", "help": "firmware image", "type": "string"}, {"name": "type", "implied-name": true, "help": "emulated machine", "type": "string"}, ...]}, to make it a bit more obvious that '-M str' and '-machine str' are both shorthands for the preferred '-machine type=str', and that the same effect is reached via a config file that has a [machine] section. Yes. We've identified at least 3 exceptions now (acpitable, boot, smp), and exposing those exceptions in the introspection is a good idea, to make us quit adding new ones. How much work are we able to do before hard freeze? How much work are we willing to accept as bug fix after hard freeze? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org