• E
    qapi: Start converting to new qapi union layout · f51d8fab
    Eric Blake 提交于
    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 non-variant
    member's name.
    
    This patch is the front end for a series that converts to a
    saner qapi union layout.  By the end of the series, we will no
    longer have the type/kind mismatch, and all tag values will be
    under a named union, which requires clients to access
    'obj->u.value' instead of 'obj->value'.  But since the
    conversion touches a number of files, it is easiest if we
    temporarily support BOTH layouts simultaneously.
    
    Given a simple union qapi type:
    
    { 'union':'Foo', 'data': { 'a':'int', 'b':'bool' } }
    
    make the following changes in generated qapi-types.h:
    
    | struct Foo {
    |-    FooKind kind;
    |-    union { /* union tag is @kind */
    |+    union {
    |+        FooKind kind;
    |+        FooKind type;
    |+    };
    |+    union { /* union tag is @type */
    |         void *data;
    |         int64_t a;
    |         bool b;
    |+        union { /* union tag is @type */
    |+            void *data;
    |+            int64_t a;
    |+            bool b;
    |+        } u;
    |     };
    | };
    
    Flat unions do not need the anonymous union for the tag member,
    as we already fixed that to use the member name instead of 'kind'
    back in commit 0f61af3e.
    
    One additional change is needed in qapi.py: check_union() now
    needs to check for collisions with 'type' in addition to those
    with 'kind'.
    
    Later, when the conversions are complete, we will remove the
    duplication hacks, and also drop the check_union() restrictions.
    
    Note, however, that we do not rename the generated enum, which
    is still 'FooKind'.  A further patch could generate implicit
    enums as 'FooType', but while the generator already reserved
    the '*Kind' namespace (commit 4dc2e690), there are already QMP
    constructs with '*Type' naming, which means changing our
    reservation namespace would have lots of churn to C code to
    deal with a forced name change.
    Signed-off-by: NEric Blake <eblake@redhat.com>
    Message-Id: <1445898903-12082-13-git-send-email-eblake@redhat.com>
    [Commit message tweaked slightly]
    Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
    f51d8fab
qapi.py 57.3 KB