From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33323 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pxi3G-0000XL-Rr for qemu-devel@nongnu.org; Thu, 10 Mar 2011 10:45:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pxi3F-0005ms-5C for qemu-devel@nongnu.org; Thu, 10 Mar 2011 10:45:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pxi3E-0005mE-T0 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 10:45:21 -0500 Message-ID: <4D78F207.70306@redhat.com> Date: Thu, 10 Mar 2011 17:45:11 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <1299460984-15849-20-git-send-email-aliguori@us.ibm.com> <4D778117.9060505@redhat.com> <4D778545.7040403@codemonkey.ws> <4D778797.9090602@redhat.com> <4D778E07.5070408@codemonkey.ws> <4D78C69F.6010003@redhat.com> <4D78DC5A.3000601@codemonkey.ws> <4D78DF3A.9000600@redhat.com> <4D78EF67.4060009@codemonkey.ws> In-Reply-To: <4D78EF67.4060009@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Luiz Capitulino , Markus Armbruster , qemu-devel@nongnu.org On 03/10/2011 05:33 PM, Anthony Liguori wrote: > > We pretty much need to keep the QEMU signature the same. That would > mean an internal signature of: > > BlockIoErrorEvent *qmp_connect_block_io_error_event(Error **errp) > { > } > > So the marshal function would then need to do something like: > > void qmp_marshal_connect_block_io_error_event(QmpState *state, QDict > *args, QObject **ret_data, Error **errp) > { > BlockIoErrorEvent *ev; > QObject *tag = qdict_get_obj(args, "tag"); > > ev = qmp_connect_block_io_error_event(errp); > qmp_state_add_connection(state, ev->signal, tag); > } That can be mashed around however we like. > > That's not too bad, but would the schema be: > > [ 'connect-block-io-error-event', {}, 'BLOCK_IO_ERROR' ] > > Or would it be: > > [ 'connect-block-io-error-event', { 'tag': 'variant' }, 'none' ] > > I'm really opposed to adding a variant type to the schema. I'm also > not a big fan of there not being a 1-1 relationship to the wire > protocol and the C API. > > I think it's easy to rationalize 'this is how events are marshalled' > vs. 'for events, a totally different declaration is generated'. Under my latest proposal it wouldn't be in the schema at all (like command tags are not in the schema) since it's a protocol-level entity. >> 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's not really a subscription to an event. It is an event. No, the event happens (potentially) multiple times. Or zero. You don't "get" the event, you ask qemu to notify you. > > Maybe signal accessor is the wrong word. Maybe signal factory conveys > a better notion of what it is. It's even more confusing to me. > >>> >>> > { '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. > > Not all events are updates of data. BLOCK_IO_ERROR is a great example > of this. There is no useful information that can be sent after a > connection. You could say the blockdev's state is fine, or it has encountered an error. How do you detect if there's an error if you've crashed (you=client in this case)? > >> btw2, I now nominate subscribe and unsubscribe as replacements for >> get and put. > > Subscribe implies sub/pub in my mind and we're not publishing events > so I don't think it fits the model. > > A pub/sub event model would be interesting to think through but > without a global namespace and object model, I don't think we can make > it fit well. I feel we're still not communicating. What does 'get-*-event' mean? I think you're using some nomenclature that is unfamiliar to me. > That's why I'm using signal/slots. It's much more conducive to a > procedural model. I still don't follow. We have a connection, over which we ask the other side to let us know when something happens, then that other side lets us know when it happens, then we ask it to stop, then it stops. There are no signals or slots anywhere. If there are in the code, let's not mix it up with the protocol. >> That makes a C centric wire protocol. Clients don't have to be C. > > But a C client is by far the most important of all clients--QEMU. If > we use QMP extensively internally, then we guarantee that the API is > expressive and robust. No, internally we have the most scope to fix mistakes. > > If we build the API only for third-party clients, we end up with > pretty much what we have today. An API with good intentions but > that's more or less impossible to use in practice. Or we have something that's nice for C but hard to use or inconsistent with whatever language a management client is written in. -- error compiling committee.c: too many arguments to function