[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: 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: 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.


Anthony Liguori

  Is there a reason to
change the events from a wire protocol perspective?



Anthony Liguori

reply via email to

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