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

[Markus Armbruster]

Paolo Bonzini <pbonzini at 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.

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

> (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?

> (c) do not add any more QemuOpts options without a schema, and use
> -object instead.
>
> Then:
>
> (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?

> (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*.

> Do you agree?

It depends :)