7:16 a.m.
[Adding Luiz...]
Paolo Bonzini <pbonzini(a)redhat.com> writes:
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).
Do you mean -rtc?
-msg takes a timestamp=on/off argument. I guess that doesn't feel too
forced, because we could conceivably have more settings related to error
reporting.
Do you mean to suggest new options should always be done in a way that
makes them fit into QemuOpts?
How would you add something like -S, -nodefaults, or -daemonize?
> However, we need to somehow stuff those into QemuOpts anyway, so
> -readconfig / -writeconfig can cover them.
Yep.
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.
>> (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,?".
We're discussing introspection via QMP, so "-device driver,help"
doesn't
count.
qom-list-types with argument "implements": "device" together with
device-list-properties indeed lets you introspect device models and
their properties. You then need to to know how to translate that to
the command line. For instance, you need to know that "type":
"on/off"
in the former means "type": "boolean" in the latter, and so forth.
What I'd like to see is more unified introspection, not this smattering
of one-offs hacked up without too much thought to serve some immediate
need we have now.
We already have something that aspires to be our unified interface
description: QAPI schemata. Perhaps we should make it our unified
introspection mechanism while we're at it.
-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
The irony is that -enable-fips should not exist :)
- -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.
Possible misunderstanding on my part. I was afraid you were arguing to
solve -object introspection *instead* of Amos's incremental improvement,
but that doesn't seem to be the case.
[...]