[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 10:49:06 -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 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.


Anthony Liguori


reply via email to

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