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/04/2015 09:58 AM, Markus Armbruster wrote:
>> Caution, rough edges.
>> 
>
>> 
>>   The empty object type is used when a command takes no arguments or
>>   produces no results.
>
>
>> +++ b/scripts/qapi.py
>
>> @@ -1050,6 +1054,9 @@ class QAPISchema(object):
>>                    ('bool',   'boolean', 'bool',     'false'),
>>                    ('any',    'value',   'QObject' + pointer_suffix , 
>> 'NULL')]:
>>              self._def_builtin_type(*t)
>> +        self.the_empty_object_type = QAPISchemaObjectType(':empty', None, 
>> None,
>> +                                                          [], None)
>> +        self._def_entity(self.the_empty_object_type)
>
> 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': {},
>             'branch2': { 'integer': 'int' } } }

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?

> but having _make_implicit_object_type() return None caused subsequent
> failures.  Normalizing to always use the special ':empty' might be worth
> doing if you hoist this work earlier; here's the diff I was playing with.

I experimented in that direction as well, but didn't like my results
much.  I'll look at your experimental patch more closely later.

> And while at it, should types like 'Abort' and 'ChardevDummy' (which are
> both intentionally empty) normalize to the same ':empty' type during
> introspection, or is it okay if two separate types with the same (lack
> of) member contents can result in separate type numbers in the
> introspection?

I think it's okay from an introspection point of view.  Client's
shouldn't rely on type names anyway, and we don't (promise to) normalize
structurally identical types.  We don't promise not to, either.

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.