|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2) |
Date: | Thu, 17 Mar 2011 08:28:45 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 |
On 03/17/2011 08:15 AM, Kevin Wolf wrote:
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.
No, it's more complicated than that unfortunately. The old events are "broadcast events". The new event/signal model requires explicit registration. There is a capabilities negotiation feature that let's us disable broadcast events.
So from the wire perspective, a newer client will never see/care about broadcast events.
If I understand right, the problem with the current events isn't even on the protocol level, which would be visible externally,
No, the problem with the old events is that they aren't registered/maskable. So even if you don't care about BLOCK_IO_ERROR, you're getting the notification. Plus, we'd like to add the ability to add a tag to events when we register them.
The other problem is that events are all global today. BLOCK_IO_ERROR is a good example of this. It's really an error that's specific to a block device and it passes the name of the block device that it's specific to as an argument. But if we have a masking mechanism it could only globally enable/disable BLOCK_IO_ERROR for all devices.
It would be much nicer to be able to enable the event for specific block devices. This requires some protocol visible changes. I'm still writing up these changes but hope to have something for review soon.
but just that it doesn't map to the C interface in the way you like.
I think I've maybe been using "C interface" to much. The current event wire protocol doesn't map to any client interface well.
Regards, Anthony Liguori
Is there a reason to change the events from a wire protocol perspective? Kevin
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |