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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 28/01/2014 12:55, Markus Armbruster ha scritto:
> Paolo Bonzini <pbonzini@redhat.com> 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 :)
>