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

[Anthony Liguori]

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