Re: [Qemu-devel] [PATCH] full introspection support for QMP

[Anthony Liguori <aliguori@us.ibm.com>]

Eric Blake <eblake@redhat.com> writes:

> On 07/02/2013 09:39 AM, Daniel P. Berrange wrote:
>>>> Maybe I'm being too meta here, but why not just return qapi-schema.json
>>>> as a string and call it as day?
>>>
>>> Because qapi-schema.json requires further parsing.  For example, how is
>>> a client supposed to know that '*foo':'int' means that there is an
>>> argument named 'foo' but it is optional?  The rule of thumb with QMP is
>>> that if you have to post-process JSON output, then the JSON was not
>>> designed correctly.
>> 
>> Arguably that rule of thumb would apply equally to the QEMU
>> build scripts which already parse qapi-schema.json. It could
>> be possible to normalize qapi-schema.json somewhat to remove
>> this 2-stage parsing if we went down this route.
>
> Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
> follow a more rigid format if that made it easier to use it as-is with
> less post-processing.  It won't be very nice to backport such a
> conversion, but I don't know how much distros are planning on
> backporting introspection in the first place.

We consume the schema in QEMU.  No reason for us to consume it in a
different format than libvirt.

We're all after the same thing.

Regards,

Anthony Liguori

>
>> 
>> I'm finding it hard to clearly see what the 2 different proposed
>> data formats look like against each other. Can someone give some
>> examples, showing the data that would need to be parsed in each
>> format, for a couple of examples.
>
> My proposal (but not quite what was implemented in _this_ version of
> Amos' patch) has been:
>
> qapi-schema.json:
>
> { 'command': 'add_client',
>   'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
>             '*tls': 'bool' } }
>
> My proposal:
>
>
> => { "execute": "query-qmp-schema",
>      "arguments": { "name": "add_client" } }
> <= { "return": [
>      { "name": "add_client",
>        "type": "command",
>        "data": [
>          { "name": "protocol",
>            "type": "str" },
>          { "name": "fdname",
>            "type": "str" },
>          { "name": "skipauth",
>            "type": "bool",
>            "optional": true },
>          { "name": "tls",
>            "type": "bool",
>            "optional": true }
>        ] } ] }
>
> Note that one other benefit of breaking out "optional" into its own dict
> member: we are free to expand the dict to add new members, such as a
> '*default':'str' member (present when "optional":true, and with the
> stringized value of the default value used if "name" is not present).
> Of course, to be able to express a default value, we already have to
> modify the syntax stored in qapi-schema.json in the first place, which
> takes us back to the argument of a one-time conversion of the .json file
> to actually use a more formal typing system in the first place.

I really think that we want schema introspection to return the exact
content of qapi-schema.json.

I don't think we need an overly verbose schema though and I don't really
understand why { 'name': 'tls', 'type': 'bool', 'optional': true } is
better than { '*name': 'bool' }

Regards,

Anthony Liguori

>
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org