From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUUFm-0001MT-Mg for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:04:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUUFj-0001Kk-2p for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:04:58 -0500 Received: from [199.232.76.173] (port=49801 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUUFi-0001KX-LK for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:04:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35917) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUUFh-0001gd-SP for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:04:54 -0500 Date: Mon, 11 Jan 2010 22:04:36 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] QMP forward compatibility support Message-ID: <20100111220436.14c662a5@doriath> In-Reply-To: <4B4B748B.6010008@codemonkey.ws> References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@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: armbru@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Mon, 11 Jan 2010 12:57:15 -0600 Anthony Liguori wrote: > On 01/11/2010 12:34 PM, Luiz Capitulino wrote: > > Hi. > > > > We (Markus and I) are working on getting QMP forward compatibility support, > > supported. :) > > > > We have a plan for it and I'd like to ask the CC'ed people to review it. > > > > Needless to say, but the objective here is to add new commands, arguments, > > async messages and protocol features w/o breaking existing clients. > > > > General Plan > > ------------ > > > > 1. QMP should describe itself, ie. it should dump all accepted commands, > > their replies and arguments, async messages and protocol features. All in > > JSON format > > > > 2. Protocol features are advertised by the (already existent) capabilities > > array, but are _disabled_ by default. The exception is async messages, > > which are _enabled_ by default > > > > Any reason to have an exception like this? As async messages were one of the reasons for having QMP, I thought that there was a consensus that making it part of the "original" protocol was ok, meaning that they would be always available. That's the only reason. > > 3. We should add command(s) to enable/disable protocol features > > > > 4. Proper feature negotiation is done in pause mode. That's, clients > > interested in enabling new protocol features should start QEMU in > > pause mode and enable the features they are interested in using > > > > Why does this matter? > > We should be careful to support connecting to a VM long after it's been > started so any requirement like this is likely to cause trouble. If I understood Markus's concerns correctly, he thinks that feature negotiation should happen before the protocol is "running", ie. make it part of the initial handshake. Now, if everything is disabled by default and qemu might be running already, do we really need to have a handshake?