From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8A5W-00024H-Tt for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:06:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8A5R-00021b-PW for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:06:06 -0500 Received: from [199.232.76.173] (port=35321 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8A5R-00021S-9Q for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:06:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60415) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8A5Q-0000CO-Hg for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:06:00 -0500 Date: Wed, 11 Nov 2009 12:03:25 +0200 From: "Michael S. Tsirkin" Message-ID: <20091111100325.GB3387@redhat.com> References: <20090921224430.610da97b@doriath> <87my4l1e4e.fsf@pike.pond.sub.org> <20090924093146.66191c37@doriath> <87r5twqxo7.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r5twqxo7.fsf@pike.pond.sub.org> Subject: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: aliguori@us.ibm.com, avi@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Thu, Sep 24, 2009 at 03:28:40PM +0200, Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Thu, 24 Sep 2009 00:37:53 +0200 > > Markus Armbruster wrote: > > > >> Luiz Capitulino writes: > >> > >> [...] > >> > 2.2 Server Greeting > >> > ------------------- > >> > > >> > Right when connected the Server will issue a greeting message, which signals > >> > that the connection has been successfully established and that the Server is > >> > waiting for commands. > >> > > >> > The format is: > >> > > >> > { "QEMU": json-string, "QMP": json-string, "capabilities": json-array } > >> > > >> > Where, > >> > > >> > - The "QEMU" member contains the QEMU version > >> > - The "QMP" member contains the QMP version > >> > - The "capabilities" member specify the availability of features beyond the > >> > baseline specification > >> > >> What about capability negotiation? Server offers capabilities, client > >> can accept or decline them. > >> > >> [...] > > > > I think the easiest way to have this would be to add a > > monitor command to disable capabilities. Like a command to > > disable async messages. > > Greeting capabilities (for lack of a better word) are for the protocol. > Changing protocol capabilities while you use the protocol is awkward. > Better do it in an initial handshake. If we use this to supppress/enable messages, I think it's clear we need to support changing them on the fly. > Case in point: if you disable asynchronous messages with a command, you > still have to be prepared to receive one between initial handshake and > completion of the disable command. If I have to ignore them anyway, why > bother with disabling them? For debug messages, sending and discarding them might have performance impact. > The problem becomes more serious if we ever want to add a capability > that isn't fully backward compatible. Lack of feature negotiation > limits protocol evolvability. Some kind of version is the usualy way to do this. -- MST