[libvirt] [Qemu-devel] fix/re-do query-command-line-options
Paolo Bonzini
pbonzini at redhat.com
Tue Jan 28 13:35:35 UTC 2014
Il 28/01/2014 14:16, Markus Armbruster ha scritto:
>>> 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?
I meant -rt, but -rtc applies just as well. :)
> -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?
Yes. Not into *existing* QemuOpts of course.
> How would you add something like -S, -nodefaults, or -daemonize?
I would add -nodefaults and -S to -machine. I would deprecate
-daemonize. But that's just for the sake of -readconfig. Consumers of
introspection can just "know" that those options are there.
> 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.
Yeah.
>>>> (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.
Yes. That's what I actually meant. O:-)
> 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.
QOM introspection can use QAPI schemata. Property types should be one of:
* child<ClassName>
* link<ClassName>
* QAPI scalar type
* QAPI compound type
I see QOM introspection as orthogonal to QAPI introspection, and
QemuOpts introspection as complementary to both:
command line introspection QMP introspection
| | | |
| v | |
v QOM introspection <--' |
QemuOpts | |
introspection v |
QAPI introspection <-----------'
Makes any sense? :)
>>>> (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.
Well, I was arguing against this series. I think it provides little
benefit and has a comparatively high cost in terms of future backwards
compatibility.
I was arguing for ignoring non-QemuOpts options and focus on what really
matters, which is QemuOpts, QOM and QAPI introspection. The first is
already there and can be fixed by adding schemata for -acpitable and
friends. QAPI introspection is already being tackled by Amos.
QOM/-object is indeed the elephant in the room, but luckily we have
enough few users that I believe we can do it if we agree on the right
design.
Paolo
More information about the libvir-list
mailing list