From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUPSB-0000lZ-O6 for qemu-devel@nongnu.org; Mon, 11 Jan 2010 13:57:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUPS7-0000ga-8x for qemu-devel@nongnu.org; Mon, 11 Jan 2010 13:57:27 -0500 Received: from [199.232.76.173] (port=33587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUPS7-0000gN-28 for qemu-devel@nongnu.org; Mon, 11 Jan 2010 13:57:23 -0500 Received: from mail-qy0-f189.google.com ([209.85.221.189]:39175) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUPS6-0003JV-1a for qemu-devel@nongnu.org; Mon, 11 Jan 2010 13:57:22 -0500 Received: by qyk27 with SMTP id 27so9556891qyk.20 for ; Mon, 11 Jan 2010 10:57:18 -0800 (PST) Message-ID: <4B4B748B.6010008@codemonkey.ws> Date: Mon, 11 Jan 2010 12:57:15 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QMP forward compatibility support References: <20100111163422.0d86d2bb@doriath> In-Reply-To: <20100111163422.0d86d2bb@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: armbru@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com 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? > 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. Regards, Anthony Liguori