From patchwork Thu Nov 12 01:17:42 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 543170 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id CEB431402BF for ; Thu, 12 Nov 2015 12:20:32 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=comcast.net header.i=@comcast.net header.b=BIpg97Iq; dkim-atps=neutral Received: from localhost ([::1]:43900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwgYw-0005Xs-RX for incoming@patchwork.ozlabs.org; Wed, 11 Nov 2015 20:20:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwgWT-0001gw-MR for qemu-devel@nongnu.org; Wed, 11 Nov 2015 20:18:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwgWP-0003NJ-JV for qemu-devel@nongnu.org; Wed, 11 Nov 2015 20:17:57 -0500 Received: from resqmta-po-04v.sys.comcast.net ([96.114.154.163]:60928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwgWP-0003N0-E3 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 20:17:53 -0500 Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-04v.sys.comcast.net with comcast id gRHp1r0084yXVJQ01RHt6m; Thu, 12 Nov 2015 01:17:53 +0000 Received: from red.redhat.com ([24.10.254.122]) by resomta-po-06v.sys.comcast.net with comcast id gRHi1r00F2fD5rL01RHsLQ; Thu, 12 Nov 2015 01:17:52 +0000 From: Eric Blake To: qemu-devel@nongnu.org Date: Wed, 11 Nov 2015 18:17:42 -0700 Message-Id: <1447291062-11011-5-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1447291062-11011-1-git-send-email-eblake@redhat.com> References: <1447291062-11011-1-git-send-email-eblake@redhat.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1447291073; bh=9bqH9+uAIJ7yepDnsCMngz5fg8jyaqwMviJiUOTYL6A=; h=Received:Received:From:To:Subject:Date:Message-Id; b=BIpg97IqnYI4QcewZBRBJcSk9+b9UNgZM5KRKdTVcosZzFJSMsg8lQNJVn2TGZ0n1 2MvAwBpE6tMzSUiyopze58XJ5c8S6H9q2Vqgrnl/MYfwpRoI664fT4zYreS8eY/osH xDeUF+wfNhNWsX1OFvBYSUWMMC3ezGLBbkOOViOLiztIVjho24wwFC3vSu95X/eWru 3IqrSXvzDY2c+DnRaufi1CT/AlBHT0sHgSnKVyqgxMAW7hrZtksA52lwI5/pzpCqq+ 1WiUl2XGWRhPvuWmnSj6W/LJLBzw0rj1GumbTsom2F3zFX10gUuHx8MHXR/ezU5YT1 LM5IMfON2018A== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.114.154.163 Cc: armbru@redhat.com, Luiz Capitulino Subject: [Qemu-devel] [PATCH for-2.5 4/4] qapi: Expose ErrorClass through introspection X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Introspection is already able to describe all possible commands and their valid argument types. But consider what happens if a future qemu extends the ErrorClass enum. It is feasible that a client will want to know whether the server is new enough to send the new error class as a result of a particular failure scenario, or even desire to refuse to talk to a server too old to know about the error class. But since no existing commands reference the ErrorClass type, introspection was silent on the set of recognized error classes. Solve this by adding a new optional parameter to qmp_capabilities. Because it is optional, no existing client is broken, but now it is referenced in introspection. Meanwhile, a client can supply a list of error class strings that it expects the server to know about, and the qapi parser will accept the command only if all the client's strings were recognized. Note that we are using this only as a one-way verification, and not a two-way negotiation method (that is, a client omitting an error class string does NOT require the server to avoid sending that error class, and the server's output is unchanged except for whether it rejects the attempt with an error). Signed-off-by: Eric Blake --- docs/qmp-spec.txt | 16 ++++++++++++++++ monitor.c | 6 +++++- qapi-schema.json | 10 +++++++--- qmp-commands.hx | 2 +- 4 files changed, 29 insertions(+), 5 deletions(-) diff --git a/docs/qmp-spec.txt b/docs/qmp-spec.txt index 4fb10a5..594f969 100644 --- a/docs/qmp-spec.txt +++ b/docs/qmp-spec.txt @@ -247,6 +247,22 @@ Clients should use the qmp_capabilities command to enable capabilities advertised in the Server's greeting (section '2.2 Server Greeting') they support. +With a new enough server, the client can pass an argument 'errors' +with a list of error class strings that the server must support; if +the server does not recognize one of the error classes, the command +will fail and the Server remains in negotiation mode. + +C: { "execute": "qmp_capabilities", + "arguments": { "errors": [ "None" ] } } +S: { "error": { "class": "GenericError", + "desc": "Invalid parameter 'None'" } } +C: { "execute": "qmp_capabilities", + "arguments": { "errors": [ "GenericError" ] } } +S: { "return": {} } + +However, the Server is still free to return error classes not +mentioned by the Client. + When the qmp_capabilities command is issued, and if it does not return an error, the Server enters in Command mode where capabilities changes take effect, all commands (except qmp_capabilities) are allowed and asynchronous diff --git a/monitor.c b/monitor.c index 608c70f..3c2cf1e 100644 --- a/monitor.c +++ b/monitor.c @@ -599,8 +599,12 @@ static void monitor_qapi_event_init(void) qmp_event_set_func_emit(monitor_qapi_event_queue); } -void qmp_qmp_capabilities(Error **errp) +void qmp_qmp_capabilities(bool has_errors, ErrorClassList *errors, + Error **errp) { + /* If we get here, the qapi front end has already validated that + * any errors supplied by the user are recognized, so we have + * nothing further to do */ cur_mon->qmp.in_command_mode = true; } diff --git a/qapi-schema.json b/qapi-schema.json index ce2dd45..1545f9c 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -23,18 +23,22 @@ ## # @Capabilities # -# The set of recognized QMP capabilities; currently empty. +# Used to determine the set of recognized QMP capabilities. +# +# @errors: #optional A list of ErrorClass strings that the server +# must recognize (however, the server is free to return +# errors that were not in the list supplied by the client). # # Since 2.5 ## -{ 'struct': 'Capabilities', 'data': {} } +{ 'struct': 'Capabilities', 'data': { '*errors': ['ErrorClass'] } } ## # @qmp_capabilities: # # Enable QMP capabilities. # -# Arguments: None. +# Arguments: See documentation of Capabilities. # # Example: # diff --git a/qmp-commands.hx b/qmp-commands.hx index 672fcfc..1d02031 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -2087,7 +2087,7 @@ Example: EQMP { .name = "qmp_capabilities", - .args_type = "", + .args_type = "errors:q?", .params = "", .help = "enable QMP capabilities", .mhandler.cmd_new = qmp_marshal_qmp_capabilities,