From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nc25k-0000vP-Tm for qemu-devel@nongnu.org; Mon, 01 Feb 2010 14:37:48 -0500 Received: from [199.232.76.173] (port=39214 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nc25k-0000uz-D5 for qemu-devel@nongnu.org; Mon, 01 Feb 2010 14:37:48 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nc25i-0005iV-NG for qemu-devel@nongnu.org; Mon, 01 Feb 2010 14:37:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64552) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nc25i-0005iJ-9e for qemu-devel@nongnu.org; Mon, 01 Feb 2010 14:37:46 -0500 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o11JbiMQ029484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Feb 2010 14:37:45 -0500 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support References: <1264686180-29845-1-git-send-email-lcapitulino@redhat.com> <20100201162234.0f144f3f@doriath> Date: Mon, 01 Feb 2010 20:37:41 +0100 In-Reply-To: <20100201162234.0f144f3f@doriath> (Luiz Capitulino's message of "Mon, 1 Feb 2010 16:22:34 -0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org Luiz Capitulino writes: > On Mon, 01 Feb 2010 18:08:27 +0100 > Markus Armbruster wrote: > >> Luiz Capitulino writes: >> >> > Feature negotiation allows clients to enable new QMP capabilities they >> > support and thus allows QMP to envolve in a compatible way. >> > >> > A capability is a new QMP feature and/or protocol change which is not part of >> > the core protocol as defined in the QMP spec. >> >> Well, it becomes part of the protocol then. But I understand what you >> mean. >> >> > Feature negotiation is implemented by, among other changes, adding >> > mode-oriented support to QMP, which comprehends the following: >> > >> > o Two modes: handshake and operational >> > o All QMP Monitors start in handshake mode >> > o In handshake mode only commands to query/enable/disable QMP capabilities are >> > allowed (there are few exceptions) >> > o Clients can switch to the operational mode at any time >> > o In Operational mode most commands are allowed and QMP capabilities changes >> > made in handshake mode take effect >> > >> > Please, note that we don't have any capability yet. So, the most visable >> > change in this series is that now Clients must switch to operational mode to >> > be able to issue 'regular' commands. >> > >> > Session example: >> > >> > """ >> > {"QMP": {"capabilities": []}} >> > >> > { "execute": "query-qmp-mode" } >> > {"return": {"mode": "handshake"}} >> > >> > { "execute": "stop" } >> > {"error": {"class": "CommandNotFound", "desc": "The command stop has not been found", "data": {"name": "stop"}}} >> > >> > { "execute": "qmp_capability_enable", "arguments": { "name": "foobar" } } >> > {"error": {"class": "InvalidParameter", "desc": "Invalid parameter name", "data": {"name": "name"}}} >> > >> > { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } } >> > {"return": {}} >> > >> > { "execute": "query-qmp-mode" } >> > {"return": {"mode": "operational"}} >> > >> > { "execute": "stop" } >> > {"return": {}} >> > >> > """ >> >> I don't doubt your design does the job. I just think it's overly >> general. I had something far more stupid in mind: >> >> client connects >> server -> client: version & capability offer (one message) >> again: >> client -> server: capability selection (one message) >> server -> client: either okay or error (one message) >> if error goto again >> connection is now ready for commands >> >> No modes. The distinct lack of generality is a design feature. > > I like the simplicity and if we were allowed to change later I'd > do it. > > The question is if we will ever want features to be _configured_ > before the protocol is operational. In this case we'd need to > pass feature arguments through the capability selection command, > which will get ugly and hard to use/understand. > > Mode oriented support doesn't have this limitation. Maybe we > won't never really use it, but it's safer. 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. If we need more *protocol* configuration than that, then we've grown a few bells & whistles to many, I'd say.