From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42349 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Poxo6-00021x-4e for qemu-devel@nongnu.org; Mon, 14 Feb 2011 07:45:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Poxnv-0003Mq-R7 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 07:45:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Poxnv-0003Me-I5 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 07:45:23 -0500 Date: Mon, 14 Feb 2011 10:45:17 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [RFC] qapi: events in QMP Message-ID: <20110214104517.32b77291@doriath> In-Reply-To: <4D5920ED.6020104@redhat.com> References: <4D581E04.1020901@codemonkey.ws> <4D58FADB.3010005@redhat.com> <4D591A01.4030105@codemonkey.ws> <4D5920ED.6020104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Markus Armbruster , qemu-devel On Mon, 14 Feb 2011 13:32:45 +0100 Kevin Wolf 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.