From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47293 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pzv9y-0000Qe-Rl for qemu-devel@nongnu.org; Wed, 16 Mar 2011 14:09:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pzv9w-0000mQ-9C for qemu-devel@nongnu.org; Wed, 16 Mar 2011 14:09:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pzv9v-0000mJ-Uo for qemu-devel@nongnu.org; Wed, 16 Mar 2011 14:09:24 -0400 Date: Wed, 16 Mar 2011 15:09:18 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2) Message-ID: <20110316150918.718b425a@doriath> In-Reply-To: <4D80DE65.5080800@codemonkey.ws> References: <1299884745-521-1-git-send-email-aliguori@us.ibm.com> <20110316113428.21c599a3@doriath> <4D80DE65.5080800@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org, Avi Kivity , Markus Armbruster , Adam Litke On Wed, 16 Mar 2011 10:59:33 -0500 Anthony Liguori wrote: > 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. Agreed. > 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. Agreed. > 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). I disagree. To access a C interface from a high-level language you usually have to write bindings. Using something like QMP instead of writing bindings is a lot easier. Also, what's the problem with C consumers using QMP? Libvirt is C, and it does it just fine. So, my personal position on shifting the direction is: I think it's if we treat the C interface as something internal to QEMU. > > +## > > +# @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. Ok. > > > 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). > > > Most of these problems seems to go away just by making libqmp internal > > to QEMU, then I think all this work would rock big time :-) > > For 0.15.0, libqmp is internal to QEMU. We need to think very hard > before making it an external interface. Ok. > But the same sort of compatibility considerations apply to using QMP > within QEMU. If you add a new field to a function call, we need to > modify any internal usage of the API. What's the problem of doing this? > If we add a field to a structure, > as long as we use feature flags (we do), only the places that care to > set that field need to worry about it. Why do we need this in an internal interface?