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.