Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
> 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. :)
Can't find -rt in output of -help.
>> -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.
I meant QemuOpts-the-mechanism, so no misunderstanding here.
>> 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.
I'd be fine with a patch that makes all existing options that don't take
a QemuOpts argument sugar for options that do.
I'd rather not promise "all options will take an argument, or desugar
into some option that takes an argument, forever and ever". But I don't
see the need for such a promise. If we decide we want such options, we
just have to do the necessary work to make them visible in
introspection.
>> 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.
Documentation job.
However, desugaring the existing options could well be more work than
extending command line introspection and -readconfig/-writeconfig to
cover them. Dunno.
>>>>> (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? :)
What do your arrows mean?
Is QemuOpts separate because it needs to be, or just because it exists,
and nobody can be bothered to fold it into one of the other things?
>>>>> (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'm can't yet see how making options without arguments visible in
query-command-line-options increases our compatibility liability, but
maybe you can enlighten me :)
Here's CommandLineOptionInfo's schema:
##
# @CommandLineOptionInfo:
#
# Details about a command line option, including its list of parameter details
#
# @option: option name
#
# @parameters: an array of @CommandLineParameterInfo
#
# Since 1.5
##
{ 'type': 'CommandLineOptionInfo',
'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
Example: description of -msg, which takes a QemuOpts argument whose only
key is "timestamp":
{"option": "msg"}, "parameters": [{"name": "timestamp", "type": "boolean"}]}
Example: description of -smbios, which takes a QemuOpts argument that
accepts any key=value:
{"option": "smbios", "parameters": []}
Not the order we put them on the wire; I took the liberty to use a more
readable one.
An option without an argument fits right in, like this:
{"option": "enable-fips"}
Less weird than the "parameters": [] we use for "anything goes".
> I was arguing for ignoring non-QemuOpts options and focus on what
> really matters, which is QemuOpts, QOM and QAPI introspection.
Point taken.
Can we really ignore non-QemuOpts, or do we have to make them sugar for
QemuOpts so they're visible in QemuOpts 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.
Both QAPI introspection and QOM introspection are obviously valuable
jobs.
My questions are what is to be done to plug the gaps in command line
introspection short term, and how command line introspection should work
long term.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list