From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PULL 22/25] qapi: Finish converting to new qapi union layout
Date: Fri, 30 Oct 2015 16:42:51 +0100 [thread overview]
Message-ID: <1446219774-1802-23-git-send-email-armbru@redhat.com> (raw)
In-Reply-To: <1446219774-1802-1-git-send-email-armbru@redhat.com>
From: Eric Blake <eblake@redhat.com>
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 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 parallel support for 'kind' and 'obj->value'.
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;
| };
The testsuite still contains some examples of artificial restrictions
(see flat-union-clash-type.json, for example) that are no longer
technically necessary, now that there is no longer a collision between
enum tag values and non-variant member names; but fixing this will be
done in later patches, in part because some further changes are required
to keep QAPISchema*.check() from asserting. Also, a later patch will
add a reservation for the member name 'u' to avoid a collision between a
user's non-variant names and our internal choice of C union name.
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 4dc2e69), 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: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-23-git-send-email-eblake@redhat.com>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
scripts/qapi-types.py | 26 +++++---------------------
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 1420e00..7e35bb6 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -149,23 +149,10 @@ struct %(c_name)s {
if base:
ret += gen_struct_fields([], base)
else:
- # TODO As a hack, we emit both 'kind' and 'type'. Ultimately, we
- # want to use only 'type', but the conversion is large enough to
- # require staging over several commits.
- ret += mcgen('''
- union {
- %(c_type)s kind;
- %(c_type)s type;
- };
-''',
- c_type=c_name(variants.tag_member.type.name))
+ ret += gen_struct_field(variants.tag_member.name,
+ variants.tag_member.type,
+ False)
- # TODO As a hack, we emit the union twice, once as an anonymous union
- # and once as a named union. Ultimately, we want to use only the
- # named union version (as it avoids conflicts between tag values as
- # branch names competing with non-variant QMP names), but the conversion
- # is large enough to require staging over several commits.
- tmp = ''
# FIXME: What purpose does data serve, besides preventing a union that
# has a branch named 'data'? We use it in qapi-visit.py to decide
# whether to bypass the switch statement if visiting the discriminator
@@ -174,7 +161,7 @@ struct %(c_name)s {
# should not be any data leaks even without a data pointer. Or, if
# 'data' is merely added to guarantee we don't have an empty union,
# shouldn't we enforce that at .json parse time?
- tmp += mcgen('''
+ ret += mcgen('''
union { /* union tag is @%(c_name)s */
void *data;
''',
@@ -183,17 +170,14 @@ struct %(c_name)s {
for var in variants.variants:
# Ugly special case for simple union TODO get rid of it
typ = var.simple_union_type() or var.type
- tmp += mcgen('''
+ ret += mcgen('''
%(c_type)s %(c_name)s;
''',
c_type=typ.c_type(),
c_name=c_name(var.name))
- ret += tmp
- ret += ' ' + '\n '.join(tmp.split('\n'))
ret += mcgen('''
} u;
- };
};
''')
--
2.4.3
next prev parent reply other threads:[~2015-10-30 15:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 15:42 [Qemu-devel] [PULL 00/25] QAPI patches Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 01/25] tests/qapi-schema: Test for reserved names, empty struct Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 02/25] qapi: More idiomatic string operations Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 03/25] qapi: More robust conditions for when labels are needed Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 04/25] qapi: Reserve '*List' type names for list types Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 05/25] qapi: Reserve 'q_*' and 'has_*' member names Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 06/25] vnc: Hoist allocation of VncBasicInfo to callers Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 07/25] qapi-visit: Split off visit_type_FOO_fields forward decl Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 08/25] qapi-types: Refactor base fields output Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 09/25] qapi: Prefer typesafe upcasts to qapi base classes Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 10/25] qapi: Unbox base members Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 11/25] qapi-visit: Remove redundant functions for flat union base Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 12/25] qapi: Start converting to new qapi union layout Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 13/25] qapi-visit: Convert " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 14/25] tests: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 15/25] block: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 16/25] sockets: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 17/25] net: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 18/25] char: " Markus Armbruster
2015-10-30 20:01 ` [Qemu-devel] [PATCH] fixup! " Eric Blake
2015-11-02 9:10 ` Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 19/25] input: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 20/25] memory: " Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 21/25] tpm: " Markus Armbruster
2015-10-30 15:42 ` Markus Armbruster [this message]
2015-10-30 15:42 ` [Qemu-devel] [PULL 23/25] qapi: Reserve 'u' member name Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 24/25] qapi: Simplify gen_struct_field() Markus Armbruster
2015-10-30 15:42 ` [Qemu-devel] [PULL 25/25] qapi-schema: mark InetSocketAddress as mandatory again Markus Armbruster
2015-10-30 19:47 ` [Qemu-devel] [PULL 00/25] QAPI patches Peter Maydell
2015-10-30 20:03 ` Eric Blake
2015-10-30 20:10 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1446219774-1802-23-git-send-email-armbru@redhat.com \
--to=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).