qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension
Date: Mon, 14 Jul 2014 12:31:32 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/14/2014 12:12 PM, Luiz Capitulino wrote:
>>>> 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.

I may take a stab at removing raw inline structs after 2.1 is released,
if no one beats me to it.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]