On Mon, 14 Feb 2011 13:32:45 +0100
Kevin Wolf <kw...@redhat.com> 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.
