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

[Anthony Liguori]

On 03/17/2011 09:04 AM, Kevin Wolf wrote:
> > 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.
> What's the problem with registering them?

You could add a simple mask/unmask event to the current protocol.  But 
that doesn't let you filter events for a given object.  As I mentioned 
in the previous note, I would like to be able to only receive 
BLOCK_IO_ERROR for certain devices.

>   If you want to stop client
> from doing this you must introduce a special case for obsolete events
> that cannot be registered. Do we gain anything from this?

Actually, the old style events are distinct from the new signals.  They 
cannot be registered/unregistered.  My intention is for new clients to 
just ignore that they exist.

> > 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.
> I wonder if the old, more generic event couldn't be generated
> automatically if the more specific signal is triggered in the block code.

Yes, this is what I'm going to try to do.  This is already how the 
patches I sent out work but now that I have the new signal model, it 
requires a little more tweaking.

But this is the advantage of being able to consume interfaces within 
QEMU.  As long as the block layer exposes a signal mechanism that 
provides the same information, we can hide the old style events entirely 
within the QMP layer by registering for the new style signals and 
created old style events.

> > >    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.
> If you mean their broadcast style, that's not really related to nesting
> or struct vs. argument.

I meant structs vs. arguments too.

I'd like to do:

import qmp

def io_error(blockdev, operation, action):
   if operation == 'stop':
       ....

srv = qmp.ServerProxy(...)

srv.connect('IO_ERROR', io_error)

Python has the same problem re: arguments.  If we add a new argument to 
a signal, then it breaks the Python client library.  At the same time, 
when possible, it's nice to use argument syntax because the alternative is:

import qmp

def io_error(args):
    if args['action'] == 'stop':
       ....

Which isn't quite as nice to me.  So I don't want to preclude having the 
ability to have a signal with a few arguments but we just have to be 
careful that we're not goign to need to add more arguments later.  If we 
do, then we should make sure there's a structure there too.

Regards,

Anthony Liguori

> Kevin