[Top][All Lists]

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

Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v

From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2)
Date: Thu, 17 Mar 2011 14:15:02 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

Am 17.03.2011 13:46, schrieb Anthony Liguori:
> On 03/17/2011 07:21 AM, Kevin Wolf wrote:
>>>> Another detail is that, event extension is more important than command
>>>> extension, because it's probably going to happen. I think it would be very
>>>> bad to add new events just because we wanted to add a new field.
>>> The way this is typically handled is that signals tend to pass
>>> structures instead of lots of fields.  For instance, most of the GDK
>>> events just pass a structure for the event (like GdkButtonEvent).
>> Can we do that with existing events or would we break the external
>> interface because we'd have to nest everything one level deeper?
> We have to introduce new versions of existing events anyway so we can 
> make sure to nest the structures appropriately.  I think BLOCK_IO_ERROR 
> is the only one that isn't doing this today FWIW.

But then we must always send both events in order to maintain
compatibility, right? That sucks.

If I understand right, the problem with the current events isn't even on
the protocol level, which would be visible externally, but just that it
doesn't map to the C interface in the way you like. Is there a reason to
change the events from a wire protocol perspective?


reply via email to

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