From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58398 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0CB5-0007jF-3p for qemu-devel@nongnu.org; Thu, 17 Mar 2011 08:19:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0CB3-0004NI-N9 for qemu-devel@nongnu.org; Thu, 17 Mar 2011 08:19:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0CB3-0004Ms-6Q for qemu-devel@nongnu.org; Thu, 17 Mar 2011 08:19:41 -0400 Message-ID: <4D81FCDA.6060601@redhat.com> Date: Thu, 17 Mar 2011 13:21:46 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2) References: <1299884745-521-1-git-send-email-aliguori@us.ibm.com> <20110316113428.21c599a3@doriath> <4D80DE65.5080800@codemonkey.ws> In-Reply-To: <4D80DE65.5080800@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , Avi Kivity , Adam Litke , qemu-devel@nongnu.org, Luiz Capitulino Am 16.03.2011 16:59, schrieb Anthony Liguori: > On 03/16/2011 09:34 AM, Luiz Capitulino wrote: >> On Fri, 11 Mar 2011 17:05:30 -0600 >> Anthony Liguori wrote: >> >>> For more information about the background of QAPI, see >>> http://wiki.qemu.org/Features/QAPI >>> >>> This series depends on 'QAPI Round 0' which I posted earlier. >>> >>> Since v2, the major changes are: >>> >>> - Switch to a multiline code emitter to ease readability >>> - Use named parameters for escape sequences >>> - Add support for proxy commands >>> - Add support for asynchronous commands >>> >>> This version still adds a -qmp2 option. This is the only practical way I know >>> to have testable code while not merging 200 patches all at once. >> I've started reviewing this and my first impression is that this seems to be >> real good. However, there's a lot of code here and some parts of it are a bit >> complicated, so I need more time to do a thorough review and testing. >> >> Having said that, my only immediate concern is weather this will have any >> negative side effects on the wire protocol, today or in the future. >> >> I mean, a C library has different extensibility constraints and functionality >> requirements than a high-level protocol and tying/mixing the two can have >> bad side effects, like this small one (patch 12/15): > > C library is not quite as important as C interface. I want QMP to be an > interface that we consume internally because that will make QMP a strong > external interface. > > A fundamental design characteristic for me is that first and foremost, > QMP should be a good C interface and that the wire representation should > be easy to support in a good C interface. > > This is a shift in our direction but the good news is that the practical > impact is small. But I don't think there's a lot of value of focusing > on non-C consumers because any non-C consumer is capable of consuming a > good C interface (but the inverse is not true). > >> +## >> +# @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'. > > I tried very hard to make events useful without changing the wire > protocol significantly but I've failed there. > > I've got a new proposal for handling events that introduces the concept > of a signal on the wire and the notion of connecting and disconnecting > from signals. > >> 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. > > The way this is typically handled is that signals tend to pass > structures instead of lots of fields. For instance, most of the GDK > events just pass a structure for the event (like GdkButtonEvent). Can we do that with existing events or would we break the external interface because we'd have to nest everything one level deeper? Kevin