From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzsCq-0003cO-2D for qemu-devel@nongnu.org; Wed, 16 Mar 2011 11:00:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzsCp-0005Mk-23 for qemu-devel@nongnu.org; Wed, 16 Mar 2011 11:00:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzsCo-0005MM-P6 for qemu-devel@nongnu.org; Wed, 16 Mar 2011 11:00:10 -0400 Date: Wed, 16 Mar 2011 12:00:04 -0300 From: Luiz Capitulino Message-ID: <20110316120004.4cf1cac4@doriath> In-Reply-To: <4D80CE17.7010005@redhat.com> References: <1299884745-521-1-git-send-email-aliguori@us.ibm.com> <20110316113428.21c599a3@doriath> <4D80CE17.7010005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Anthony Liguori , Avi Kivity , Markus Armbruster , Adam Litke On Wed, 16 Mar 2011 15:49:59 +0100 Paolo Bonzini wrote: > On 03/16/2011 03:34 PM, Luiz Capitulino wrote: > > +## > > +# @put_event: > > +# > > +# Disconnect a signal. This command is used to disconnect from a signal based > > +# on the handle returned by a signal accessor. > > +# > > +# @tag: the handle returned by a signal accessor. > > +# > > +# Returns: Nothing on success. > > +# If @tag is not a valid handle, InvalidParameterValue > > +# > > +# Since: 0.15.0 > > > > The name 'signal' (at least today) doesn't make sense on the wire protocol, > > 'put_event' probably doesn't make sense in the C library, nor does 'event'. > > > > Another detail is that, event extension is more important than command > > extension, because it's probably going to happen. I think it would be very > > bad to add new events just because we wanted to add a new field. > > What if events were always passed a single struct, with the first field > being a bitmask saying which (or how many) fields have been filled? > > It is quite ugly to work that way when calling functions, but it's not > too bad when you are writing the callees. And it's the code generator > that writes the function calls in the case of libqmp... I was also wondering if it's possible to only make the most recent version available in the wire protocol and all existing ones in libqmp. But I need to read more code in order to know that.