From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ5oO-0006mS-2q for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:13:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ5oI-0006en-Uy for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:13:19 -0400 Received: from [199.232.76.173] (port=43056 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ5oI-0006eV-NQ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:13:14 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]:56481) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ5oF-0004eQ-RS for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:13:12 -0400 Received: by pzk15 with SMTP id 15so33676pzk.4 for ; Tue, 23 Jun 2009 06:13:10 -0700 (PDT) Message-ID: <4A40D4C1.4040608@codemonkey.ws> Date: Tue, 23 Jun 2009 08:12:33 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> In-Reply-To: <4A40989C.1050805@redhat.com> 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: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Hi Luiz, The specification looks pretty good. >> + >> +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. >> + 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. How would asynchronous commands work? Could you give an example of doing live migration through QMP? Regards, Anthony Liguori