From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34042 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PztFE-0006en-GE for qemu-devel@nongnu.org; Wed, 16 Mar 2011 12:06:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PztF0-0007hu-RW for qemu-devel@nongnu.org; Wed, 16 Mar 2011 12:06:32 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:34554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PztF0-0007ho-Nm for qemu-devel@nongnu.org; Wed, 16 Mar 2011 12:06:30 -0400 Received: by ywl41 with SMTP id 41so866593ywl.4 for ; Wed, 16 Mar 2011 09:06:30 -0700 (PDT) Message-ID: <4D80E001.1050207@codemonkey.ws> Date: Wed, 16 Mar 2011 11:06:25 -0500 From: Anthony Liguori 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> <4D80CE17.7010005@redhat.com> <20110316120004.4cf1cac4@doriath> In-Reply-To: <20110316120004.4cf1cac4@doriath> 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: Luiz Capitulino Cc: Anthony Liguori , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity , Adam Litke , Paolo Bonzini On 03/16/2011 10:00 AM, Luiz Capitulino wrote: > 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. I don't quite follow. libqmp works with all previous versions of QMP. New functions will return a CommandNotFound error. In fact, you can run test-libqmp -p /0.14 and it will run the regressions against the QMP server shipped in 0.14[1]. This is why I used version prefixes :-) [1] test-libqmp right now doesn't have a way to select which method you use for connecting to the QMP server and right now assumes a unix socket at a well known location. It doesn't add the right parameter to QEMU to launch this way because in my tree, this is all implicit so you need to patch test-libqmp to explicitly add that qmp socket. Regards, Anthony Liguori