Re: [Qemu-devel] fix/re-do query-command-line-options

[Paolo Bonzini]

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