Re: [libvirt] [Qemu-devel] fix/re-do query-command-line-options
Il 28/01/2014 15:28, Markus Armbruster ha scritto:
I'd rather not promise "all options will take an argument,
or desugar
into some option that takes an argument, forever and ever". But I don't
see the need for such a promise. If we decide we want such options, we
just have to do the necessary work to make them visible in
introspection.
Agreed.
>> The question is whether we should extend QemuOpts to cover
options
>> without arguments, or change the options without arguments to fit into
>> existing QemuOpts, e.g. by making them all syntactic sugar for a
>> suitable QemuOpts-style option.
>>
>> If we do the latter, we need to tell customers of command line
>> introspection to look only for the desugared forms.
>
> Yeah.
Documentation job.
However, desugaring the existing options could well be more work than
extending command line introspection and -readconfig/-writeconfig to
cover them. Dunno.
Definitely. For example, -watchdog-action could become a -device
option, which is nontrivial to implement.
"git log -p -SDEF\( -- qemu-options.hx" lets you find commits that added
options. The last non-QemuOpts option we added was -sandbox, in 1.2.0,
shortly preceded by -no-user-config and -qtest. So we can also tell
customers of command line introspection "this is the set of non-sugar
non-QemuOpts options as of 1.2".
> command line introspection QMP introspection
> | | | |
> | v | |
> v QOM introspection <--' |
> QemuOpts | |
> introspection v |
> QAPI introspection <-----------'
>
> Makes any sense? :)
What do your arrows mean?
Nothing specific :) Something like "requires".
Is QemuOpts separate because it needs to be, or just because it
exists,
and nobody can be bothered to fold it into one of the other things?
There is some difference between QemuOpts and the others, in that it's
out of necessity a human-oriented interface---or at least a "more"
human-oriented interface. So the optimistic me says it needs to be.
But I'm not 100% sure.
I'm can't yet see how making options without arguments
visible in
query-command-line-options increases our compatibility liability, but
maybe you can enlighten me :)
Maybe there's none.
Example: description of -smbios, which takes a QemuOpts argument
that
accepts any key=value:
{"option": "smbios", "parameters": []}
Not the order we put them on the wire; I took the liberty to use a more
readable one.
An option without an argument fits right in, like this:
{"option": "enable-fips"}
Do we know for sure that libvirt or anyone else won't hiccup on the
missing parameters?
Can we really ignore non-QemuOpts, or do we have to make them sugar
for
QemuOpts so they're visible in QemuOpts introspection?
See above for my answer.
> QOM/-object is indeed the elephant in the room, but luckily we
have
> enough few users that I believe we can do it if we agree on the right
> design.
Both QAPI introspection and QOM introspection are obviously valuable
jobs.
My questions are what is to be done to plug the gaps in command line
introspection short term, and how command line introspection should work
long term.
Short term, we definitely have to do something about the mismatches
between option name and QemuOpts group name (boot-opts/smp-opts, resp.
1.0 and 1.6.0). And we have to document all the suboptions in the
QemuOpts schema, with the exceptions of -device, -object (both to be
satisfied with the QOM schema) and -blockdev (QAPI schema). And we have
to provide a way for libvirt to know that query-command-line-options is
reliable.
Long term, I'm not sure we need more introspection than what we have.
But regarding the command line, it would be definitely nice to move more
stuff to QemuOpts, thus making -readconfig more complete.
Paolo