From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ9fg-0003Ka-6Y for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:20:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ9fb-0003JX-Kx for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:20:35 -0400 Received: from [199.232.76.173] (port=41580 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ9fb-0003JQ-Cb for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:20:31 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43467) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ9fa-0005Kn-O6 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:20:31 -0400 Date: Tue, 23 Jun 2009 14:20:20 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090623142020.39700a6c@doriath> In-Reply-To: <4A40D4C1.4040608@codemonkey.ws> References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> <4A40D4C1.4040608@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: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Avi Kivity On Tue, 23 Jun 2009 08:12:33 -0500 Anthony Liguori wrote: > The specification looks pretty good. Thanks, used previous discussions as my main reference. > >> + > >> +3.3.1 Server Greeting > >> +--------------------- > >> + > >> +Sent when a new connection is opened. > >> + > >> +Format: + OK QEMU QMP > >> +Example: + OK QEMU 0.10.50 QMP 0.1 > >> > > > > Clients should never make decisions based on the qemu or qmp version. > > Rather, we should provide a facility to query the availability of > > features. > > I agree, but I'd suggest leaving the QMP version in there for insurance > purposes in case we really screw up and need to bump the version. In > fact, having the client also negotiate the QMP version isn't a bad idea. Will keep. > >> + o Command completion failed > >> + > >> + Format: - ERR > >> + Example: - ERR could not find network device 'foo' > >> + > >> > > > > Maybe add a numeric error code (to be defined by individual commands). > > I think copying HTTP makes sense here. Ok, as I said in others emails I was a bit agains't it but have changed my mind after three being in favor. :) > How would asynchronous commands work? Could you give an example of > doing live migration through QMP? Avi has already explained this part. To be honest, I didn't have this clear in my mind, but Avi's suggestion is what makes sense to me.