qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 16/17] qapi: Finish converting to new qapi un


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v9 16/17] qapi: Finish converting to new qapi union layout
Date: Thu, 22 Oct 2015 16:50:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

> We have two issues with our qapi union layout:
> 1) Even though the QMP wire format spells the tag 'type', the
> C code spells it 'kind', requiring some hacks in the generator.
> 2) The C struct uses an anonymous union, which places all tag
> values in the same namespace as all non-variant members. This
> leads to spurious collisions if a tag value matches a QMP name.
>
> This patch is the back end for a series that converts to a
> saner qapi union layout.  Now that all clients have been
> converted to use 'type' and 'obj->u.value', we can drop the
> temporary support for 'kind' and 'obj->value', and undo the
> temporary restriction against 'u' as a branch name.
>
> Given a simple union qapi type:
>
> { 'union':'Foo', 'data': { 'a':'int', 'b':'bool' } }
>
> this is the overall effect, when compared to the state before
> this series of patches:
>
> | struct Foo {
> |-    FooKind kind;
> |-    union { /* union tag is @kind */
> |+    FooKind type;
> |+    union { /* union tag is @type */
> |         void *data;
> |         int64_t a;
> |         bool b;
> |-    };
> |+    } u;
> | };
>
> Note, however, that we do not rename the generated enum, which
> is still 'FooKind'.  A further patch could generate implicit
> enums as 'FooType', but that causes more churn to C code, and
> gets harder since the generator already reserved the '*Kind'
> namespace, but there are already QMP constructs with '*Type'
> naming which means we cannot easily reserve it for qapi.
> Signed-off-by: Eric Blake <address@hidden>

If you edit the commit message of PATCH 07, make sure to edit this one
to match.

Patch looks good.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]