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

[Paolo Bonzini]

Il 28/01/2014 12:55, Markus Armbruster ha scritto:
> Paolo Bonzini <address@hidden> writes:
>
> > Il 28/01/2014 10:36, Markus Armbruster ha scritto:
> > > I think the data you can usefully collect with this approach is
> > > approximately the data getopt_long()[*] gets: list of named command line
> > > options, and whether they take an argument.
> > >
> > > You can use this data to fill in options not covered by QemuOpts.  This
> > > is a definite improvement.
> > >
> > > It still falls short of fully solving the command line introspection
> > > problem.
> > >
> > > However, I'm not into rejecting imperfect incremental improvements we
> > > can have now in favor of perfect solutions we can maybe have some day.
> > > Go right ahead with your incremental improvement!
> >
> > It depends.  If we can agree on the following:
> >
> > (a) do not add non-QemuOpts options (we haven't for a while)
>
> That would mean we can't ever add an option that doesn't take an
> argument again.

We can add it under an existing QemuOpts group or invent a new one (like 
we did for -rt or -msg).

> However, we need to somehow stuff those into QemuOpts anyway, so
> -readconfig / -writeconfig can cover them.

Yep.

> > (b) document the QemuOpts schema for -acpitable, -smbios, -netdev,
> > -net. These options validate the options with OptsVisitor, so we could
> > do without QemuOpts schema, but we know the schema won't bitrot
> > because we never remove suboptions.
>
> -device?

-device already provides its own introspection via "qom-list-types" and 
"-device driver,?".

-object doesn't have an equivalent of "-device driver,?", but that's a 
separate problem.

> > (a) there is no need to cover non-QemuOpts options in
> > query-command-line-options.  libvirt can treat them as crystallized.
>
> Some options are undef #ifdef.  That's actually a good idea, because it
> permits finding out which options are available via command line
> introspection.
>
> Now, what if a non-QemuOpts option is under #ifdef?  I haven't
> checked...  Even if there isn't one now, are we ready to give up the
> ability to do that for good?

There are some:

- legacy slirp options -tftp/-bootp/-redir/-smb

- -enable-fips is what triggered this discussion, but we found another 
solution in Libvirt

- -tpmdev is enabled only if CONFIG_TPM, but its presence can be queried 
via qom-list-types too.

> > (b) documenting the schemata is not harder than what Amos proposed.
> >
> > (c) schema inspection for objects remains a problem, but one that we
> > need to solve anyway so it doesn't affect query-command-line-options.
>
> As long as we don't have such schema inspection, I'm rather reluctant to
> reject alternative means to solve problems people have *now*.

Note the "doesn't affect query-command-line-options" part.  Amos's patch 
do not solve the problem of which classes can be instantiated with 
-object, or of which properties can be used.

Paolo

> > Do you agree?
>
> It depends :)