Re: [libvirt] [Qemu-devel] fix/re-do query-command-line-options
Il 28/01/2014 12:55, Markus Armbruster ha scritto:
Paolo Bonzini <pbonzini(a)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 :)