From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqthT-00039U-Ou for qemu-devel@nongnu.org; Thu, 24 Sep 2009 15:09:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqthO-00038r-2x for qemu-devel@nongnu.org; Thu, 24 Sep 2009 15:09:54 -0400 Received: from [199.232.76.173] (port=37182 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqthN-00038o-SS for qemu-devel@nongnu.org; Thu, 24 Sep 2009 15:09:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38020) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqthN-0001J9-EL for qemu-devel@nongnu.org; Thu, 24 Sep 2009 15:09:49 -0400 Date: Thu, 24 Sep 2009 16:09:39 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree Message-ID: <20090924160939.228a41f9@doriath> In-Reply-To: <87r5twqxo7.fsf@pike.pond.sub.org> 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-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com On Thu, 24 Sep 2009 15:28:40 +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. Maybe it's better, but I'm wondering if it's worth it, considering the implementation and usage "complexity". > 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. This is true, although I think it's a good practice for programs to start QEMU in pause mode and only put it to run after some setup is done. This also has to be considered with the handshake approach, eg. if QEMU is started before the application connects to it, we will have a window of time where several things may have happened in QEMU and this may affect the protocol. Async messages is an example. > If I have to ignore them anyway, why bother with disabling them? I can see two separate things here: 1. do we need/want the handshake approach? 2. Should async messages be considered a capability? If disabling async messages is not needed, then it should not be considered a capability. > 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. Why? Enabling 'what you want' as suggested by Avi doesn't have the same end result?