From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF59x-0000zk-B9 for qemu-devel@nongnu.org; Thu, 29 Aug 2013 12:33:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VF59r-0001T5-Vx for qemu-devel@nongnu.org; Thu, 29 Aug 2013 12:33:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF59r-0001Sw-OK for qemu-devel@nongnu.org; Thu, 29 Aug 2013 12:33:19 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7TGXIZu012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Aug 2013 12:33:18 -0400 Date: Thu, 29 Aug 2013 12:33:15 -0400 From: Luiz Capitulino Message-ID: <20130829123315.63432366@redhat.com> In-Reply-To: <20130829160650.GA2435@dhcp-200-207.str.redhat.com> References: <1374584606-5615-1-git-send-email-kwolf@redhat.com> <1374584606-5615-3-git-send-email-kwolf@redhat.com> <20130821033805.GA7028@amosk.info> <20130827155859.GP648@dhcp-200-207.str.redhat.com> <20130829095247.526626e5@redhat.com> <20130829160650.GA2435@dhcp-200-207.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/18] qapi-types.py: Implement 'base' for unions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Amos Kong , qemu-devel@nongnu.org, stefanha@redhat.com, armbru@redhat.com On Thu, 29 Aug 2013 18:06:50 +0200 Kevin Wolf wrote: > Am 29.08.2013 um 15:52 hat Luiz Capitulino geschrieben: > > On Tue, 27 Aug 2013 17:58:59 +0200 > > Kevin Wolf wrote: > > > > > Am 21.08.2013 um 05:38 hat Amos Kong geschrieben: > > > > On Tue, Jul 23, 2013 at 03:03:10PM +0200, Kevin Wolf wrote: > > > > > The new 'base' key in a union definition refers to a struct type, which > > > > > is inlined into the union definition and can represent fields common to > > > > > all kinds. > > > > > > > > > > For example the following schema definition... > > > > > > > > > > { 'type': 'BlockOptionsBase', 'data': { 'read-only': 'bool' } } > > > > > > > > > > { 'union': 'BlockOptions', > > > > > 'base': 'BlockOptionsBase', > > > > > 'data': { > > > > > 'raw': 'BlockOptionsRaw' > > > > > 'qcow2': 'BlockOptionsQcow2' > > > > > } } > > > > > > > > > > ...would result in this generated C struct: > > > > > > > > > > struct BlockOptions > > > > > { > > > > > BlockOptionsKind kind; > > > > > union { > > > > > void *data; > > > > > BlockOptionsRaw * raw; > > > > > BlockOptionsQcow2 * qcow2; > > > > > }; > > > > > bool read_only; > > > > > }; > > > > > > > > > > Signed-off-by: Kevin Wolf > > > > > --- > > > > > scripts/qapi-types.py | 16 ++++++++++++++-- > > > > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py > > > > > index e1239e1..9882b95 100644 > > > > > --- a/scripts/qapi-types.py > > > > > +++ b/scripts/qapi-types.py > > > > > @@ -157,7 +157,12 @@ typedef enum %(name)s > > > > > > > > > > return lookup_decl + enum_decl > > > > > > > > > > -def generate_union(name, typeinfo): > > > > > +def generate_union(expr): > > > > > + > > > > > + name = expr['union'] > > > > > + typeinfo = expr['data'] > > > > > + base = expr.get('base') > > > > > + > > > > > ret = mcgen(''' > > > > > struct %(name)s > > > > > { > > > > > @@ -176,6 +181,13 @@ struct %(name)s > > > > > > > > > > ret += mcgen(''' > > > > > }; > > > > > +''') > > > > > + > > > > > + if base: > > > > > + struct = find_struct(base) > > > > > + ret += generate_struct_fields(struct['data']) > > > > > > > > > > > > generate_struct_fields() doesn't exist in upstream. > > > > > > > > [qemu-upstream]$ grep generate_struct_fields -r * > > > > scripts/qapi-types.py: ret += generate_struct_fields(struct['data']) > > > > [qemu-upstream]$ > > > > > > Yup, something went wrong while applying the series, that patch was > > > simply dropped (and interestingly it didn't result in any conflicts or > > > compile errors). I'll include it in my next pull request. > > > > Strange, it appears on your pull request... But anyway, your series > > made it into 1.6.0, so I think we'll need the missing patch in 1.6.1 too? > > There's no user in 1.6 (or would we have a build failure) because I > didn't merge blockdev-add, so I guess it doesn't matter. I won't say it's a huge deal, but any downstreamers basing on 1.6 will have a hard time if they backport blockdev-add or any future command that my depend on this.