Re: [Qemu-devel] Re: [RFC] qapi: events in QMP

[Luiz Capitulino]

On Mon, 14 Feb 2011 13:32:45 +0100
Kevin Wolf <address@hidden> wrote:

> Am 14.02.2011 13:03, schrieb Anthony Liguori:
> > On 02/14/2011 03:50 AM, Kevin Wolf wrote:
> >> Am 13.02.2011 19:08, schrieb Anthony Liguori:
> >>> Proposal for events in QAPI
> >>>
> >>> For QAPI, I'd like to model events on the notion of signals and
> >>> slots[2].  A client would explicitly connect to a signal through a QMP
> >>> interface which would result in a slot being added that then generates
> >>> an event.  Internally in QEMU, we could also connect slots to the same
> >>> signals.  Since we don't have an object API in QMP, we'd use a pair of
> >>> connect/disconnect functions that had enough information to identify the
> >>> signal.
> >>>
> >>> Example:
> >>>
> >>> We would define QEVENT_BLOCK_IO_EVENT as:
> >>>
> >>> # qmp-schema.json
> >>> { 'BlockIOEvent': {'device': 'str', 'action': 'str', 'operation': 'str'} }
> >>>
> >>> The 'Event' suffix is used to determine that the type is an event and
> >>> not a structure.  This would generate the following structures for QEMU:
> >>>
> >>> typedef void (BlockIOEventFunc)(const char *device, const char *action,
> >>> const char *operation, void *opaque);
> >>>      
> >> Why is an event not a structure? For one it makes things inconsistent
> >> (you have this 'Event' suffix magic), and it's not even convenient. The
> >> parameter list of the BlockIOEventFunc might become very long. At the
> >> moment you have three const char* there and I think it's only going to
> >> grow - who is supposed to remember the right order of arguments?
> >>
> >> So why not make the event a struct and have a typedef void
> >> (BlockIOEventFunc)(BlockIOEvent *evt)?
> >>    
> > 
> > A signal is a function call.  You can pass a structure as a parameter is 
> > you so desire but the natural thing to do is pass position arguments.
> > 
> > If you've got a ton of signal arguments, it's probably an indication 
> > that you're doing something wrong.
> 
> Yes. For example, you're taking tons of independent arguments for
> something that is logically a single entity, namely a block error event. ;-)
> 
> I'm almost sure that we'll want to add more things to this specific
> event, for example a more detailed error description (Luiz once
> suggested using errno here, but seems it hasn't made its way into
> upstream). And I would be surprised if we never wanted to add more
> information to other events, too.

So the question is: how does the schema based design support extending
commands or events? Does it require adding new commands/events?

While the current code is in really in bad shape currently, I'm not sure that
having this disadvantage will pay off the new design.