From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJ68o-0006X0-Cq
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:34:26 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJ68j-0006Su-LX
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:34:25 -0400
Received: from [199.232.76.173] (port=44867 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJ68j-0006Se-Cy
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:34:21 -0400
Received: from mx2.redhat.com ([66.187.237.31]:53348)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <ehabkost@redhat.com>) id 1MJ68i-0002D3-RK
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:34:21 -0400
Date: Tue, 23 Jun 2009 10:34:15 -0300
From: Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file
Message-ID: <20090623133415.GB6462@blackpad>
References: <cover.1245730845.git.lcapitulino@redhat.com>
	<20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com>
	<4A40D4C1.4040608@codemonkey.ws> <4A40D8F8.4050508@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A40D8F8.4050508@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: aliguori@us.ibm.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On Tue, Jun 23, 2009 at 04:30:32PM +0300, Avi Kivity wrote:
> On 06/23/2009 04:12 PM, Anthony Liguori wrote:
>> Hi Luiz,
>>
>> The specification looks pretty good.
>>
>>
>>>> +
>>>> +3.3.1 Server Greeting
>>>> +---------------------
>>>> +
>>>> +Sent when a new connection is opened.
>>>> +
>>>> +Format: + OK QEMU<version>  QMP<version>
>>>> +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.
>
> Agreed.
>
>> How would asynchronous commands work? 
>
> IMO, there aren't any.  All commands are synchronous (but may cause  
> events to be generated later).

And if there is any, we can simply convert them to synchronous commands
that cause events to be generated.

I think we could make this clear on the specification, specifying that
all commands are synchronous.

-- 
Eduardo