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

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