Re: [Qemu-devel] [PATCH RFC v3 30/32] qapi: New QMP command query-schema for QMP schema introspection

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 08/24/2015 05:30 AM, Markus Armbruster wrote:
>
>>> We mentioned moving this into its own patch.  In particular, I looked at
>>> what it would take to allow anonymous structs for flat union types:
>>>
>>> { 'union': 'Flat', 'base': 'Base',
>>>   'discriminator': 'type',
>>>   'data': { 'branch1': {},
>
> This one is particularly handy - it would avoid the need to create dummy
> types like 'Abort' that exist solely to satisfy the current qapi grammar.
>
>>>             'branch2': { 'integer': 'int' } } }
>
> This one is a bit harder to justify, but may still be useful.
>
>> 
>> We used to support inline structs in a few places, but dropped it
>> (commit 6b5abc7).  Do we really want to add them back in other places?
>
> We dropped nested structs, not anonymous structs.
>
> For comparison, here's an anonymous command struct:
>
> { 'command': 'foo', 'data': { 'i': 'int' } }
>
> vs. the corresponding named version:
>
> { 'struct': 'Foo', 'data': { 'i': 'int' } }
> { 'command': 'foo', 'data': 'Foo' }
>
> Where things would NOT be allowed due to our prohibition of nested
> structs is:
>
> { 'union': 'Flat', 'base': 'Base', 'discriminator': 'type',
>   'data': { 'okay': 'str', 'bad': { 'i': 'int' } } }

Our motivation for dropping nested structs was to avoid burning the
'name': {} struct member syntax on a trivial and rarely used
convenience, and instead make it available for a way to specify member
attributes beyond name and type.

Is there a chance we want to define simple union cases with attributes
beyond tag value and type?

I think we have a better chance to answer that question after we clean
non-simple unions.

>> Both Abort and ChardevDummy exist only because you need a type to
>> declare a simple union case.  I'd like to explore cleaning up the
>> convoluted union syntax first.  If we then still have a need for
>> empty structs, we can consider optimizing them.
>
> And that's where my patches were headed - by allowing a dict instead of
> a type name for the branches of a flat union, the syntax for flat unions
> becomes simpler, and allows us to sanely represent a
> "no-additional-members" variant without needing 'Abort' as an empty type.

Empty cases in flat unions are not a problem: simply don't mention the
tag value.

I'd like to explore doing unions in schema syntax the way we represent
them internally and in introspection.  Basically get rid of the "need to
inherit the common members from a base" nonsense.

Once that's done, we can decice whether simple unions are still
worthwhile syntactical sugar.