Re: [Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-18 Thread Markus Armbruster
Eric Blake  writes:

> On 02/17/2016 07:40 AM, Markus Armbruster wrote:
>
> There's no reason to do two malloc's for an alternate type visiting
> a QAPI struct; let's just inline the struct directly as the C union
> branch of the struct.
>
>
>>> Also, here we pass 'obj'; visit_type_FOO() had to pass '*obj' (again,
>>> because we have one less level of indirection, and 7/13 reduced the
>>> indirection required in visit_type_FOO_fields()).
>>>
 // visit_start_union() + switch dropped
 error_propagate(errp, err);
 err = NULL;
 visit_end_struct(v, );
 out:
 error_propagate(errp, err);
 }

 Why can we drop visit_start_union() + switch?
>>>
>>> visit_start_union() is dropped because its only purpose was to determine
>>> if the dealloc visitor needs to visit the default branch. When we had a
>>> separate allocation, we did not want to visit the branch if the
>>> discriminator was not successfully parsed, because otherwise we would
>>> dereference NULL.  But now that we don't have a second pointer
>>> allocation, we no longer have anything to dealloc, and we can no longer
>>> dereference NULL. Explained better in 12/13, where I delete
>>> visit_start_union() altogether.  But maybe I could keep it in this patch
>>> in the meantime, to minimize confusion.
>> 
>> Perhaps squashing the two patches together could be less confusing.
>
> Yes, I'm closer to posting v11, and in that version, visit_start_union
> is only dropped in a single patch; and this patch just inlines the
> visit_start_struct() allocation directly into the visit_type_ALT()
> rather than creating a new visit_type_alternate_ALT().
>
>> 
>>> Dropped switch, on the other hand, looks to be a genuine bug.  Eeek.
>>> That should absolutely be present, and it proves that our testsuite is
>>> not strong enough for not catching me on it.
>>>
>>> And now that you've made me think about it, maybe I have yet another
>>> idea.  Right now, we've split the visit of local members into
>>> visit_type_FOO_fields(), while leaving the variant members to be visited
>>> in visit_type_FOO()
>> 
>> Yes.  I guess that's to support visiting "implicit" structs.
>
> Up to now, we've forbidden the use of one union as a branch of another
> (but allowed a union as a branch of an alternate), so the types passed
> to visit_struct_FOO_fields() never had variants.  As part of our generic
> "object" work, I _want_ to support one union as a branch of another (as
> long as we can prove there will be no QMP name collisions); and that's
> another reason why visit_struct_FOO_fields() would need to always visit
> variants if present.
>
>
>> Let me get to this result from a different angle.  A "boxed" visit is
>> 
>> allocate hook
>> visit the members (common and variant)
>> cleanup hook
>
> Correct, and we have two choices of allocate hook: visit_start_struct()
> [allocate and consume {}, for visit_type_FOO() in general], and
> visit_start_implicit_struct() [allocate, but don't consume {}, for flat
> union branches prior to this series].
>
>> 
>> An "unboxed" visit is basically the same without the two hooks.
>
> Done anywhere we don't have a separate C struct [base classes prior to
> this series; and then this series is adding unboxed variant visits
> within flat unions and alternates].

Should work for visiting both "inlined" and "unboxed" members, shouldn't
it?

struct {
  A a;
  B b
} S;

struct {
  S *ps;// boxed member of type S
  S s;  // unboxed member of type S
  A a; B b; // inlined member of type S
}

>> 
>> "Implicit" is like unboxed, except the members are inlined rather than
>> wrapped in a JSON object.
>> 
>> So the common code to factor out is "visit the members".
>
> Yep, we're on the same wavelength, and it is looking fairly nice for
> what I'm about to post as v11.  And I like 'unboxed' better than
> 'is_member':
>
> - c_type=typ.c_type(),
> + c_type=typ.c_type(is_member=inline),
>> 
>> I don't like the name is_member.  The thing we're dealing with here is a
>> member, regardless of the value of inline.  I think it's boxed
>> vs. unboxed.
>
> Hmm. I have later patches that add a 'box':true QAPI designation to
> commands and events, to let us do qmp_command(Foo *arg, Error **errp)
> instead of qmp_command(type Foo_member1, type Foo_member2 ..., Error
> **errp) (that is, instead of breaking out each parameter, we pass them
> all boxed behind a single pointer).  What we are doing here is in the
> opposite direction - we are taking code that has boxed all the sub-type
> fields behind a single pointer, and unboxing it so that they occur
> inline in the parent type's storage.  Works for me; I'm switching to
> 'is_unboxed' as the case for when we want to omit the pointer
> designation during the member declaration.

Better.  "Unboxed" isn't tied to "member"; we 

Re: [Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-17 Thread Eric Blake
On 02/17/2016 07:40 AM, Markus Armbruster wrote:

 There's no reason to do two malloc's for an alternate type visiting
 a QAPI struct; let's just inline the struct directly as the C union
 branch of the struct.


>> Also, here we pass 'obj'; visit_type_FOO() had to pass '*obj' (again,
>> because we have one less level of indirection, and 7/13 reduced the
>> indirection required in visit_type_FOO_fields()).
>>
>>> // visit_start_union() + switch dropped
>>> error_propagate(errp, err);
>>> err = NULL;
>>> visit_end_struct(v, );
>>> out:
>>> error_propagate(errp, err);
>>> }
>>>
>>> Why can we drop visit_start_union() + switch?
>>
>> visit_start_union() is dropped because its only purpose was to determine
>> if the dealloc visitor needs to visit the default branch. When we had a
>> separate allocation, we did not want to visit the branch if the
>> discriminator was not successfully parsed, because otherwise we would
>> dereference NULL.  But now that we don't have a second pointer
>> allocation, we no longer have anything to dealloc, and we can no longer
>> dereference NULL. Explained better in 12/13, where I delete
>> visit_start_union() altogether.  But maybe I could keep it in this patch
>> in the meantime, to minimize confusion.
> 
> Perhaps squashing the two patches together could be less confusing.

Yes, I'm closer to posting v11, and in that version, visit_start_union
is only dropped in a single patch; and this patch just inlines the
visit_start_struct() allocation directly into the visit_type_ALT()
rather than creating a new visit_type_alternate_ALT().

> 
>> Dropped switch, on the other hand, looks to be a genuine bug.  Eeek.
>> That should absolutely be present, and it proves that our testsuite is
>> not strong enough for not catching me on it.
>>
>> And now that you've made me think about it, maybe I have yet another
>> idea.  Right now, we've split the visit of local members into
>> visit_type_FOO_fields(), while leaving the variant members to be visited
>> in visit_type_FOO()
> 
> Yes.  I guess that's to support visiting "implicit" structs.

Up to now, we've forbidden the use of one union as a branch of another
(but allowed a union as a branch of an alternate), so the types passed
to visit_struct_FOO_fields() never had variants.  As part of our generic
"object" work, I _want_ to support one union as a branch of another (as
long as we can prove there will be no QMP name collisions); and that's
another reason why visit_struct_FOO_fields() would need to always visit
variants if present.


> Let me get to this result from a different angle.  A "boxed" visit is
> 
> allocate hook
> visit the members (common and variant)
> cleanup hook

Correct, and we have two choices of allocate hook: visit_start_struct()
[allocate and consume {}, for visit_type_FOO() in general], and
visit_start_implicit_struct() [allocate, but don't consume {}, for flat
union branches prior to this series].

> 
> An "unboxed" visit is basically the same without the two hooks.

Done anywhere we don't have a separate C struct [base classes prior to
this series; and then this series is adding unboxed variant visits
within flat unions and alternates].

> 
> "Implicit" is like unboxed, except the members are inlined rather than
> wrapped in a JSON object.
> 
> So the common code to factor out is "visit the members".

Yep, we're on the same wavelength, and it is looking fairly nice for
what I'm about to post as v11.  And I like 'unboxed' better than
'is_member':

 - c_type=typ.c_type(),
 + c_type=typ.c_type(is_member=inline),
> 
> I don't like the name is_member.  The thing we're dealing with here is a
> member, regardless of the value of inline.  I think it's boxed
> vs. unboxed.

Hmm. I have later patches that add a 'box':true QAPI designation to
commands and events, to let us do qmp_command(Foo *arg, Error **errp)
instead of qmp_command(type Foo_member1, type Foo_member2 ..., Error
**errp) (that is, instead of breaking out each parameter, we pass them
all boxed behind a single pointer).  What we are doing here is in the
opposite direction - we are taking code that has boxed all the sub-type
fields behind a single pointer, and unboxing it so that they occur
inline in the parent type's storage.  Works for me; I'm switching to
'is_unboxed' as the case for when we want to omit the pointer
designation during the member declaration.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-17 Thread Markus Armbruster
Eric Blake  writes:

> On 02/16/2016 12:07 PM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> There's no reason to do two malloc's for an alternate type visiting
>>> a QAPI struct; let's just inline the struct directly as the C union
>>> branch of the struct.
>>>
>>> Surprisingly, no clients were actually using the struct member prior
>>> to this patch; some testsuite coverage is added to avoid future
>>> regressions.
>>>
>>> Ultimately, we want to do the same treatment for QAPI unions, but
>>> as that touches a lot more client code, it is better as a separate
>>> patch.  So in the meantime, I had to hack in a way to test if we
>>> are visiting an alternate type, within qapi-types:gen_variants();
>>> the hack is possible because an earlier patch guaranteed that all
>>> alternates have at least two branches, with at most one object
>>> branch; the hack will go away in a later patch.
>> 
>> Suggest:
>> 
>>   Ultimately, we want to do the same treatment for QAPI unions, but as
>>   that touches a lot more client code, it is better as a separate patch.
>>   The two share gen_variants(), and I had to hack in a way to test if we
>>   are visiting an alternate type: look for a non-object branch.  This
>>   works because alternates have at least two branches, with at most one
>>   object branch, and unions have only object branches.  The hack will go
>>   away in a later patch.
>
> Nicer.
>
>> 
>>> The generated code difference to qapi-types.h is relatively small,
>>> made possible by a new c_type(is_member) parameter in qapi.py:
>> 
>> Let's drop the "made possible" clause here.
>
> I was trying to document the new is_member parameter somewhere in the
> commit message, but I can agree that it could be its own paragraph
> rather than a clause here.

That could work.

>> This is in addition to visit_type_BlockdevOptions(), so we need another
>> name.
>> 
>> I can't quite see how the function is tied to alternates, though.
>> 
>
> I'm open to naming suggestions.  Also, I noticed that we have
> 'visit_type_FOO_fields' and 'visit_type_implicit_FOO'; so I didn't know
> whether to name it 'visit_type_alternate_FOO' or
> 'visit_type_FOO_alternate'; it gets more interesting later in the series
> when I completely delete 'visit_type_implicit_FOO'.
>
>>>
>>> and use it like this:
>>>
>>> | switch ((*obj)->type) {
>>> | case QTYPE_QDICT:
>>> |-visit_type_BlockdevOptions(v, name, &(*obj)->u.definition, );
>>> |+visit_type_alternate_BlockdevOptions(v, name, 
>>> &(*obj)->u.definition, );
>> 
>> Let's compare the two functions.  First visit_type_BlockdevOptions():
>> 
>
>> 
>> Now visit_type_alternate_BlockdevOptions(), with differences annotated
>> with //:
>> 
>> static void visit_type_alternate_BlockdevOptions(Visitor *v,
>> const char *name,
>> BlockdevOptions *obj, // one * less
>
> Yep, because we no longer need to malloc a second object, so we no
> longer need to propagate a change to obj back to the caller.
>
>> Error **errp)
>> {
>> Error *err = NULL;
>> 
>> visit_start_struct(v, name, NULL, 0, ); // NULL instead of 
>> // suppresses malloc
>> if (err) {
>> goto out;
>> }
>> // null check dropped (obj can't be null)
>> visit_type_BlockdevOptions_fields(v, obj, );
>
> Also, here we pass 'obj'; visit_type_FOO() had to pass '*obj' (again,
> because we have one less level of indirection, and 7/13 reduced the
> indirection required in visit_type_FOO_fields()).
>
>> // visit_start_union() + switch dropped
>> error_propagate(errp, err);
>> err = NULL;
>> visit_end_struct(v, );
>> out:
>> error_propagate(errp, err);
>> }
>> 
>> Why can we drop visit_start_union() + switch?
>
> visit_start_union() is dropped because its only purpose was to determine
> if the dealloc visitor needs to visit the default branch. When we had a
> separate allocation, we did not want to visit the branch if the
> discriminator was not successfully parsed, because otherwise we would
> dereference NULL.  But now that we don't have a second pointer
> allocation, we no longer have anything to dealloc, and we can no longer
> dereference NULL. Explained better in 12/13, where I delete
> visit_start_union() altogether.  But maybe I could keep it in this patch
> in the meantime, to minimize confusion.

Perhaps squashing the two patches together could be less confusing.

> Dropped switch, on the other hand, looks to be a genuine bug.  Eeek.
> That should absolutely be present, and it proves that our testsuite is
> not strong enough for not catching me on it.
>
> And now that you've made me think about it, maybe I have yet another
> idea.  Right now, we've split the visit of local members into
> visit_type_FOO_fields(), 

Re: [Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-16 Thread Eric Blake
On 02/16/2016 12:07 PM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> There's no reason to do two malloc's for an alternate type visiting
>> a QAPI struct; let's just inline the struct directly as the C union
>> branch of the struct.
>>
>> Surprisingly, no clients were actually using the struct member prior
>> to this patch; some testsuite coverage is added to avoid future
>> regressions.
>>
>> Ultimately, we want to do the same treatment for QAPI unions, but
>> as that touches a lot more client code, it is better as a separate
>> patch.  So in the meantime, I had to hack in a way to test if we
>> are visiting an alternate type, within qapi-types:gen_variants();
>> the hack is possible because an earlier patch guaranteed that all
>> alternates have at least two branches, with at most one object
>> branch; the hack will go away in a later patch.
> 
> Suggest:
> 
>   Ultimately, we want to do the same treatment for QAPI unions, but as
>   that touches a lot more client code, it is better as a separate patch.
>   The two share gen_variants(), and I had to hack in a way to test if we
>   are visiting an alternate type: look for a non-object branch.  This
>   works because alternates have at least two branches, with at most one
>   object branch, and unions have only object branches.  The hack will go
>   away in a later patch.

Nicer.

> 
>> The generated code difference to qapi-types.h is relatively small,
>> made possible by a new c_type(is_member) parameter in qapi.py:
> 
> Let's drop the "made possible" clause here.

I was trying to document the new is_member parameter somewhere in the
commit message, but I can agree that it could be its own paragraph
rather than a clause here.


> 
> This is in addition to visit_type_BlockdevOptions(), so we need another
> name.
> 
> I can't quite see how the function is tied to alternates, though.
> 

I'm open to naming suggestions.  Also, I noticed that we have
'visit_type_FOO_fields' and 'visit_type_implicit_FOO'; so I didn't know
whether to name it 'visit_type_alternate_FOO' or
'visit_type_FOO_alternate'; it gets more interesting later in the series
when I completely delete 'visit_type_implicit_FOO'.

>>
>> and use it like this:
>>
>> | switch ((*obj)->type) {
>> | case QTYPE_QDICT:
>> |-visit_type_BlockdevOptions(v, name, &(*obj)->u.definition, );
>> |+visit_type_alternate_BlockdevOptions(v, name, 
>> &(*obj)->u.definition, );
> 
> Let's compare the two functions.  First visit_type_BlockdevOptions():
> 

> 
> Now visit_type_alternate_BlockdevOptions(), with differences annotated
> with //:
> 
> static void visit_type_alternate_BlockdevOptions(Visitor *v,
> const char *name,
> BlockdevOptions *obj, // one * less

Yep, because we no longer need to malloc a second object, so we no
longer need to propagate a change to obj back to the caller.

> Error **errp)
> {
> Error *err = NULL;
> 
> visit_start_struct(v, name, NULL, 0, ); // NULL instead of 
> // suppresses malloc
> if (err) {
> goto out;
> }
> // null check dropped (obj can't be null)
> visit_type_BlockdevOptions_fields(v, obj, );

Also, here we pass 'obj'; visit_type_FOO() had to pass '*obj' (again,
because we have one less level of indirection, and 7/13 reduced the
indirection required in visit_type_FOO_fields()).

> // visit_start_union() + switch dropped
> error_propagate(errp, err);
> err = NULL;
> visit_end_struct(v, );
> out:
> error_propagate(errp, err);
> }
> 
> Why can we drop visit_start_union() + switch?

visit_start_union() is dropped because its only purpose was to determine
if the dealloc visitor needs to visit the default branch. When we had a
separate allocation, we did not want to visit the branch if the
discriminator was not successfully parsed, because otherwise we would
dereference NULL.  But now that we don't have a second pointer
allocation, we no longer have anything to dealloc, and we can no longer
dereference NULL. Explained better in 12/13, where I delete
visit_start_union() altogether.  But maybe I could keep it in this patch
in the meantime, to minimize confusion.

Dropped switch, on the other hand, looks to be a genuine bug.  Eeek.
That should absolutely be present, and it proves that our testsuite is
not strong enough for not catching me on it.

And now that you've made me think about it, maybe I have yet another
idea.  Right now, we've split the visit of local members into
visit_type_FOO_fields(), while leaving the variant members to be visited
in visit_type_FOO()

visit_type_FOO_fields() is static, so we can change it without impacting
the entire tree; I could add a bool parameter to that function, and write:

visit_type_FOO() {
  visit_start_struct(obj)
  

Re: [Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-16 Thread Markus Armbruster
Eric Blake  writes:

> There's no reason to do two malloc's for an alternate type visiting
> a QAPI struct; let's just inline the struct directly as the C union
> branch of the struct.
>
> Surprisingly, no clients were actually using the struct member prior
> to this patch; some testsuite coverage is added to avoid future
> regressions.
>
> Ultimately, we want to do the same treatment for QAPI unions, but
> as that touches a lot more client code, it is better as a separate
> patch.  So in the meantime, I had to hack in a way to test if we
> are visiting an alternate type, within qapi-types:gen_variants();
> the hack is possible because an earlier patch guaranteed that all
> alternates have at least two branches, with at most one object
> branch; the hack will go away in a later patch.

Suggest:

  Ultimately, we want to do the same treatment for QAPI unions, but as
  that touches a lot more client code, it is better as a separate patch.
  The two share gen_variants(), and I had to hack in a way to test if we
  are visiting an alternate type: look for a non-object branch.  This
  works because alternates have at least two branches, with at most one
  object branch, and unions have only object branches.  The hack will go
  away in a later patch.

> The generated code difference to qapi-types.h is relatively small,
> made possible by a new c_type(is_member) parameter in qapi.py:

Let's drop the "made possible" clause here.

>
> | struct BlockdevRef {
> | QType type;
> | union { /* union tag is @type */
> | void *data;
> |-BlockdevOptions *definition;
> |+BlockdevOptions definition;
> | char *reference;
> | } u;
> | };
>
> meanwhile, in qapi-visit.h, we create a new visit_type_alternate_Foo(),
> comparable to visit_type_implicit_Foo():
>
> |+static void visit_type_alternate_BlockdevOptions(Visitor *v, const char 
> *name, BlockdevOptions *obj, Error **errp)
> |+{
> |+Error *err = NULL;
> |+
> |+visit_start_struct(v, name, NULL, 0, );
> |+if (err) {
> |+goto out;
> |+}
> |+visit_type_BlockdevOptions_fields(v, obj, );
> |+error_propagate(errp, err);
> |+err = NULL;
> |+visit_end_struct(v, );
> |+out:
> |+error_propagate(errp, err);
> |+}

This is in addition to visit_type_BlockdevOptions(), so we need another
name.

I can't quite see how the function is tied to alternates, though.

>
> and use it like this:
>
> | switch ((*obj)->type) {
> | case QTYPE_QDICT:
> |-visit_type_BlockdevOptions(v, name, &(*obj)->u.definition, );
> |+visit_type_alternate_BlockdevOptions(v, name, 
> &(*obj)->u.definition, );

Let's compare the two functions.  First visit_type_BlockdevOptions():

void visit_type_BlockdevOptions(Visitor *v,
const char *name,
BlockdevOptions **obj,
Error **errp)
{
Error *err = NULL;

visit_start_struct(v, name, (void **)obj, sizeof(BlockdevOptions), 
);
if (err) {
goto out;
}
if (!*obj) {
goto out_obj;
}
visit_type_BlockdevOptions_fields(v, *obj, );
if (err) {
goto out_obj;
}
if (!visit_start_union(v, !!(*obj)->u.data, ) || err) {
goto out_obj;
}
switch ((*obj)->driver) {
case BLOCKDEV_DRIVER_ARCHIPELAGO:
visit_type_implicit_BlockdevOptionsArchipelago(v, 
&(*obj)->u.archipelago, );
break;
[All the other cases...]
default:
abort();
}
out_obj:
error_propagate(errp, err);
err = NULL;
visit_end_struct(v, );
out:
error_propagate(errp, err);
}

Now visit_type_alternate_BlockdevOptions(), with differences annotated
with //:

static void visit_type_alternate_BlockdevOptions(Visitor *v,
const char *name,
BlockdevOptions *obj, // one * less
Error **errp)
{
Error *err = NULL;

visit_start_struct(v, name, NULL, 0, ); // NULL instead of 
// suppresses malloc
if (err) {
goto out;
}
// null check dropped (obj can't be null)
visit_type_BlockdevOptions_fields(v, obj, );
// visit_start_union() + switch dropped
error_propagate(errp, err);
err = NULL;
visit_end_struct(v, );
out:
error_propagate(errp, err);
}

Why can we drop visit_start_union() + switch?

> | break;
> | case QTYPE_QSTRING:
> | visit_type_str(v, name, &(*obj)->u.reference, );
>
> Signed-off-by: Eric Blake 
>
> ---
> v10: new patch
> ---
>  scripts/qapi-types.py   | 10 ++-
>  scripts/qapi-visit.py   | 49 
> 

[Qemu-devel] [PATCH v10 10/13] qapi: Don't box struct branch of alternate

2016-02-15 Thread Eric Blake
There's no reason to do two malloc's for an alternate type visiting
a QAPI struct; let's just inline the struct directly as the C union
branch of the struct.

Surprisingly, no clients were actually using the struct member prior
to this patch; some testsuite coverage is added to avoid future
regressions.

Ultimately, we want to do the same treatment for QAPI unions, but
as that touches a lot more client code, it is better as a separate
patch.  So in the meantime, I had to hack in a way to test if we
are visiting an alternate type, within qapi-types:gen_variants();
the hack is possible because an earlier patch guaranteed that all
alternates have at least two branches, with at most one object
branch; the hack will go away in a later patch.

The generated code difference to qapi-types.h is relatively small,
made possible by a new c_type(is_member) parameter in qapi.py:

| struct BlockdevRef {
| QType type;
| union { /* union tag is @type */
| void *data;
|-BlockdevOptions *definition;
|+BlockdevOptions definition;
| char *reference;
| } u;
| };

meanwhile, in qapi-visit.h, we create a new visit_type_alternate_Foo(),
comparable to visit_type_implicit_Foo():

|+static void visit_type_alternate_BlockdevOptions(Visitor *v, const char 
*name, BlockdevOptions *obj, Error **errp)
|+{
|+Error *err = NULL;
|+
|+visit_start_struct(v, name, NULL, 0, );
|+if (err) {
|+goto out;
|+}
|+visit_type_BlockdevOptions_fields(v, obj, );
|+error_propagate(errp, err);
|+err = NULL;
|+visit_end_struct(v, );
|+out:
|+error_propagate(errp, err);
|+}

and use it like this:

| switch ((*obj)->type) {
| case QTYPE_QDICT:
|-visit_type_BlockdevOptions(v, name, &(*obj)->u.definition, );
|+visit_type_alternate_BlockdevOptions(v, name, &(*obj)->u.definition, 
);
| break;
| case QTYPE_QSTRING:
| visit_type_str(v, name, &(*obj)->u.reference, );

Signed-off-by: Eric Blake 

---
v10: new patch
---
 scripts/qapi-types.py   | 10 ++-
 scripts/qapi-visit.py   | 49 +
 scripts/qapi.py | 10 ---
 tests/test-qmp-input-visitor.c  | 29 ++-
 tests/qapi-schema/qapi-schema-test.json |  2 ++
 tests/qapi-schema/qapi-schema-test.out  |  2 ++
 6 files changed, 91 insertions(+), 11 deletions(-)

diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 2f23432..aba2847 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -116,6 +116,14 @@ static inline %(base)s *qapi_%(c_name)s_base(const 
%(c_name)s *obj)


 def gen_variants(variants):
+# HACK: Determine if this is an alternate (at least one variant
+# is not an object); unions have all branches as objects.
+inline = False
+for v in variants.variants:
+if not isinstance(v.type, QAPISchemaObjectType):
+inline = True
+break
+
 # 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
@@ -136,7 +144,7 @@ def gen_variants(variants):
 ret += mcgen('''
 %(c_type)s %(c_name)s;
 ''',
- c_type=typ.c_type(),
+ c_type=typ.c_type(is_member=inline),
  c_name=c_name(var.name))

 ret += mcgen('''
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 9ff0337..948bde4 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -15,10 +15,14 @@
 from qapi import *
 import re

-# visit_type_FOO_implicit() is emitted as needed; track if it has already
+# visit_type_implicit_FOO() is emitted as needed; track if it has already
 # been output.
 implicit_structs_seen = set()

+# visit_type_alternate_FOO() is emitted as needed; track if it has already
+# been output.
+alternate_structs_seen = set()
+
 # visit_type_FOO_fields() is always emitted; track if a forward declaration
 # or implementation has already been output.
 struct_fields_seen = set()
@@ -71,6 +75,35 @@ static void visit_type_implicit_%(c_type)s(Visitor *v, 
%(c_type)s **obj, Error *
 return ret


+def gen_visit_alternate_struct(typ):
+if typ in alternate_structs_seen:
+return ''
+alternate_structs_seen.add(typ)
+
+ret = gen_visit_fields_decl(typ)
+
+ret += mcgen('''
+
+static void visit_type_alternate_%(c_type)s(Visitor *v, const char *name, 
%(c_type)s *obj, Error **errp)
+{
+Error *err = NULL;
+
+visit_start_struct(v, name, NULL, 0, );
+if (err) {
+goto out;
+}
+visit_type_%(c_type)s_fields(v, obj, );
+error_propagate(errp, err);
+err = NULL;
+visit_end_struct(v, );
+out:
+error_propagate(errp, err);
+}
+''',
+ c_type=typ.c_name())
+return ret
+
+
 def gen_visit_struct_fields(name, base,