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

[Paolo Bonzini <pbonzini@redhat.com>]

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