[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command
Date: Thu, 10 Mar 2011 16:24:58 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 03/10/2011 04:12 PM, Anthony Liguori wrote:
On 03/10/2011 06:39 AM, Avi Kivity wrote:
What I mean is that the client should specify the handle, like it does for everything else it gives a name (netdevs, blockdevs, SCM_RIGHT fds, etc).

  { execute: listen-event, arguments: { event: blah, id: blah00001 } }
  { execute: unlisten-event arguments: { id: blah00001 } }

Yeah, I understand, it just doesn't fit the model quite as well of signal accessors.

Normally, in a signal/slot event model, you'd have some notion of an object model and/or hierarchy. For instance, with dbus, you'd do something like:

bus = dbus.SystemBus()
hal = # magic to get a hal object
device = hal.FindDeviceByCapability('media.storage')

device.connect_to_signal('media-changed', fn)

We don't have objects and I don't mean to introduce them, but I like the idea of treating signals as objects and returning them via an accessor function.

So the idea is that the handle is a marshalled form of the signal object.

It's not a marshalled form, it's an opaque handle. A marshalled form doesn't destroy information.

Anyway it would work with a client-provided tag just as well. connect_to_signal() could manufacture one and provide it to the server.

{ 'BLOCK_IO_ERROR': { 'device': 'str', 'action': 'str', 'operation': 'str' } }
[ 'get-block-io-error-event': {}, 'BLOCK_IO_ERROR' }

The way we marshal a 'BLOCK_IO_ERROR' type is by generating a unique handle and returning that.

I don't follow at all. Where's the handle here? Why don't we return the BLOCK_IO_ERROR as an object, on the wire?

How we marshal an object depends on the RPC layer.

We marshal events on the wire as an integer handle. That is only a concept within the wire protocol.

I don't think it's an accurate description. We marshall an event as a json object according to the schema above (BLOCK_IO_ERROR). How we marshall a subscription to an event, or an unsubscription to an event, depends on how we specify the protocol. It has nothing to do with client or server internal rpc stubs.

We could just as easily return an object but without diving into JSON class hinting, it'd be pretty meaningless because we'd just return "{ 'handle': 32}" instead of "32".

Right, I suggest we return nothing at all. Instead the client provides the handle.

While this looks like an int on the wire, at both the server and libqmp level, it looks like a BlockIoErrorEvent object. So in QEMU:

BlockIoErrorEvent *qmp_get_block_io_error_event(Error **errp)

And in libqmp:

BlockIoErrorEvent *libqmp_get_block_io_error_event(QmpSession *sess, Error **errp)

What would the wire exchange look like?

> { 'execute': 'get-block-io-error-event' }
< { 'return' : 32 }
< { 'event': 'BLOCK_IO_ERROR', 'data': { 'action': 'stop', 'device': 'ide0-hd0', 'operation': 'read' }, 'tag': 32 }
> { 'execute': 'put-event', 'arguments': { 'tag': 32 } }

Well, I may be biased, but I prefer my variant.

btw, it's good to decree that a subscription is immediately followed by an event with the current state (which means events have to provide state and be idempotent); so the subscribe-and-query pattern is provided automatically.

btw2, I now nominate subscribe and unsubscribe as replacements for get and put.

Ignoring default events, you'll never see an event until you execute a signal accessor function. When you execute this function, you will start receiving the events and those events will carry a tag containing the handle returned by the signal accessor.

A "signal accessor" is a command to start listening to a signal?

Yes, it basically enables the signal for the session.

Okay, the subscription command.

So why not have the signal accessor provide the tag? Like execute: blah provides a tag?

How would this map to a C API? You'd either have to completely drop the notion of signal objects and use a separate mechanism to register callbacks against a tag (and lose type safety) or do some major munging to have the C API take a radically different signature than the wire protocol.

A C API could create and maintain tags under the covers (an int that keeps increasing would do).

Within libqmp, any time you execute a signal accessor, a new signal object is created of the appropriate type. When that object is destroyed, you send a put-event to stop receiving the signal.

When you connect to a signal object (via libqmp), you don't execute the signal accessor because the object is already receiving the signal.

Default events (which exist to preserve compatibility) are a set of events that are automatically connected to after qmp_capabilities is executed. Because these connections are implicit, they arrive without a handle in the event object.

At this point, libqmp just ignores default events. In the future, I'd like to add a command that can be executed before qmp_capabilities that will avoid connecting to default events.

I'm really confused. Part of that is because the conversation mixes libqmp, server API, and wire protocol. I'd like to understand the wire protocol first, everything else follows from that.

No, it's the opposite for me. We design a good C API and then figure out how to make it work well as a wire protocol. The whole point of this effort is to build an API that we can consume within QEMU such that we can start breaking large chunks of code out of the main executable.

That makes a C centric wire protocol.  Clients don't have to be C.

error compiling committee.c: too many arguments to function

reply via email to

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