From nobody Tue Nov 4 18:52:29 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1530633099366583.1541638863054; Tue, 3 Jul 2018 08:51:39 -0700 (PDT) Received: from localhost ([::1]:41233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faNac-0005eD-Lg for importer@patchew.org; Tue, 03 Jul 2018 11:51:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faNMz-0002Mp-8g for qemu-devel@nongnu.org; Tue, 03 Jul 2018 11:37:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faNMx-0005J1-4i for qemu-devel@nongnu.org; Tue, 03 Jul 2018 11:37:33 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50126 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1faNMw-0005HJ-TH for qemu-devel@nongnu.org; Tue, 03 Jul 2018 11:37:31 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D59A8163C5F for ; Tue, 3 Jul 2018 15:37:30 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-126.ams2.redhat.com [10.36.116.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5A8862026D76 for ; Tue, 3 Jul 2018 15:37:30 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 34F9B1132D72; Tue, 3 Jul 2018 17:37:28 +0200 (CEST) From: Markus Armbruster To: qemu-devel@nongnu.org Date: Tue, 3 Jul 2018 17:37:03 +0200 Message-Id: <20180703153728.2175-8-armbru@redhat.com> In-Reply-To: <20180703153728.2175-1-armbru@redhat.com> References: <20180703153728.2175-1-armbru@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 03 Jul 2018 15:37:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 03 Jul 2018 15:37:30 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'armbru@redhat.com' RCPT:'' Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 07/32] qmp: Make "id" optional again even in "oob" monitors X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Commit cf869d53172 "qmp: support out-of-band (oob) execution" made "id" mandatory for all commands when the client accepted capability "oob". This is rather onerous when you play with QMP by hand, and unnecessarily so: only out-of-band commands need an ID for reliable matching of response to command. Revert that part of commit cf869d53172 for now, but have documentation advise on the need to use "id" with out-of-band commands. Signed-off-by: Markus Armbruster Message-Id: <20180703085358.13941-8-armbru@redhat.com> Reviewed-by: Daniel P. Berrang=C3=A9 --- docs/interop/qmp-spec.txt | 13 +++++++------ monitor.c | 7 ------- 2 files changed, 7 insertions(+), 13 deletions(-) diff --git a/docs/interop/qmp-spec.txt b/docs/interop/qmp-spec.txt index 6b72b69cb1..a1d6f9ee06 100644 --- a/docs/interop/qmp-spec.txt +++ b/docs/interop/qmp-spec.txt @@ -103,16 +103,13 @@ The format for command execution is: required. Each command documents what contents will be considered valid when handling the json-argument - The "id" member is a transaction identification associated with the - command execution. It is required for all commands if the OOB - - capability was enabled at startup, and optional otherwise. The same - "id" field will be part of the response if provided. The "id" - member can be any json-value. A json-number incremented for each - successive command works fine. + command execution, it is optional and will be part of the response + if provided. The "id" member can be any json-value. A json-number + incremented for each successive command works fine. - The optional "control" member further specifies how the command is to be executed. Currently, its only member is optional "run-oob". See section "2.3.1 Out-of-band execution" for details. =20 - 2.3.1 Out-of-band execution --------------------------- =20 @@ -128,6 +125,10 @@ possibly overtaking prior in-band commands. The clien= t may therefore receive such a command's response before responses from prior in-band commands. =20 +To be able to match responses back to their commands, the client needs +to pass "id" with out-of-band commands. Passing it with all commands +is recommended for clients that accept capability "oob". + To execute a command out-of-band, the client puts "run-oob": true into execute's member "control". =20 diff --git a/monitor.c b/monitor.c index 3ad89fe1ba..0dd6e22463 100644 --- a/monitor.c +++ b/monitor.c @@ -4292,13 +4292,6 @@ static void handle_qmp_command(JSONMessageParser *pa= rser, GQueue *tokens) =20 id =3D qdict_get(qdict, "id"); =20 - /* When OOB is enabled, the "id" field is mandatory. */ - if (qmp_oob_enabled(mon) && !id) { - error_setg(&err, "Out-of-band capability requires that " - "every command contains an 'id' field"); - goto err; - } - req_obj =3D g_new0(QMPRequest, 1); req_obj->mon =3D mon; req_obj->id =3D qobject_ref(id); --=20 2.17.1