From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nck3q-0001pw-1e for qemu-devel@nongnu.org; Wed, 03 Feb 2010 13:34:46 -0500 Received: from [199.232.76.173] (port=32999 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nck3p-0001pf-Mb for qemu-devel@nongnu.org; Wed, 03 Feb 2010 13:34:45 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nck3o-0000Qs-9G for qemu-devel@nongnu.org; Wed, 03 Feb 2010 13:34:45 -0500 Received: from mail-yw0-f204.google.com ([209.85.211.204]:37325) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nck3o-0000Qo-1b for qemu-devel@nongnu.org; Wed, 03 Feb 2010 13:34:44 -0500 Received: by ywh42 with SMTP id 42so1597024ywh.28 for ; Wed, 03 Feb 2010 10:34:43 -0800 (PST) Message-ID: <4B69C1BF.5080207@codemonkey.ws> Date: Wed, 03 Feb 2010 12:34:39 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support References: <1264686180-29845-1-git-send-email-lcapitulino@redhat.com> <20100201162234.0f144f3f@doriath> <20100201175004.5b1b5cc8@doriath> In-Reply-To: <20100201175004.5b1b5cc8@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: Markus Armbruster , qemu-devel@nongnu.org On 02/01/2010 01:50 PM, Luiz Capitulino wrote: >> Capability selection could be done as an object where the name/value >> pairs are capability/argument. If you need multiple arguments for a >> capability, make the capability's value an object. >> > That's exactly what seems complicated to me, because besides performing > two functions (enable/configure) some feature setup could require > more commands to be done in a clear way. > I think the way to do this would be: server -> client: version & capabilities offer (including cap NEGOTIATE_FEATURES) client -> server: capability selection (including cap NEGOTIATE_FEATURES) server -> client: okay or error (session is now in negotiation mode) client -> server: configure features server -> client: ack/nack client -> server: change to command mode server -> client: ack/nack So Markus' proposal solves our immediate needs while making it possible to implement something more sophisticated IFF we end up needing it for some reason. It's a little more chatty than Luiz's proposal but since there isn't an obvious need now, I think it's a reasonable trade off to make. Regards, Anthony Liguori