Re: [Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 11 Jul 2014 15:22:24 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 07/11/2014 12:51 PM, Luiz Capitulino wrote:
> 
> >>>>  { 'type': 'VersionInfo',
> >>>>    'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
> >>>> +           '__com.redhat.crap': {'major': 'int', 'minor': 'int', 'micro': 'int'},
> >>>>             'package': 'str'} }
> >>>
> >>> And the fix may be as simple as ditching support for nested structs in
> >>> the first place, and rewriting this as:
> >>>
> >>> { 'type': 'VersionDetails',
> >>>   'data': { major': 'int', 'minor': 'int', 'micro': 'int'} }
> >>> { 'type': 'VersionInfo',
> >>>   'data': {'qemu': 'VersionDetails',
> >>>            '__com.redhat.crap': 'VersionDetails',
> >>>            'package': 'str' } }
> >>>
> >>> But the fact that we are still discussing makes it obvious - this is 2.2
> >>> material.
> >>
> >> Agree.  Let's ditch nested structs and see whether there are any misuses
> >> of c_var() left.
> > 
> > This is an honest question: do we really want to drop nested struct support,
> > wasn't it added by the block layer or am I just confused?
> 
> We're talking about raw inline structs - there's only 3 impacted QAPI
> typesMP commands (if I counted correctly), and they have nothing to do
> with block layer complex structs.  The idea is that we want to outlaw
> 'foo':{...} implicit structs, and instead require 'foo':'type', where
> 'type' was earlier defined with the {...} guts.  The QMP wire format
> would be unchanged; it is just a change to the QAPI template that the
> generators read.  Removing inline structs would also simplify the
> generators.  Then, with that gone, we are free to to repurpose
> 'foo':{...} for default values of optional arguments.  Here's a link to
> some of the earlier conversation:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00708.html
> https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg04268.html

Right, this makes sense. Thanks for the URLs.

Is there anyone planning on doing this? I don't think I'll have cycles
anytime soon... I'd be willing to merge my fix if nobody steps up.