From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NbzlP-0003TZ-Nx for qemu-devel@nongnu.org; Mon, 01 Feb 2010 12:08:39 -0500 Received: from [199.232.76.173] (port=45194 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NbzlO-0003Sm-9v for qemu-devel@nongnu.org; Mon, 01 Feb 2010 12:08:38 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NbzlL-0005Au-SN for qemu-devel@nongnu.org; Mon, 01 Feb 2010 12:08:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38260) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NbzlK-00059y-7B for qemu-devel@nongnu.org; Mon, 01 Feb 2010 12:08:35 -0500 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o11H8TVZ002200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Feb 2010 12:08:29 -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> Date: Mon, 01 Feb 2010 18:08:27 +0100 In-Reply-To: <1264686180-29845-1-git-send-email-lcapitulino@redhat.com> (Luiz Capitulino's message of "Thu, 28 Jan 2010 11:42:52 -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: > 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.