From patchwork Fri May 7 09:49:42 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Markus Armbruster X-Patchwork-Id: 51919 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 89165B7D28 for ; Sat, 8 May 2010 00:17:40 +1000 (EST) Received: from localhost ([127.0.0.1]:50114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OAOMy-0001Uc-TY for incoming@patchwork.ozlabs.org; Fri, 07 May 2010 10:17:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OANZk-0002uN-NX for qemu-devel@nongnu.org; Fri, 07 May 2010 09:26:44 -0400 Received: from [140.186.70.92] (port=46997 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OANZf-0005ra-57 for qemu-devel@nongnu.org; Fri, 07 May 2010 09:26:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OAKBo-0008KW-QC for qemu-devel@nongnu.org; Fri, 07 May 2010 05:49:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34506) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OAKBo-0008KF-IE for qemu-devel@nongnu.org; Fri, 07 May 2010 05:49:48 -0400 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 o479nkM3001063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 May 2010 05:49:46 -0400 Received: from blackfin.pond.sub.org (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o479niut018235; Fri, 7 May 2010 05:49:44 -0400 Received: by blackfin.pond.sub.org (Postfix, from userid 500) id 0663BD6; Fri, 7 May 2010 11:49:42 +0200 (CEST) From: Markus Armbruster To: qemu-devel@nongnu.org References: <20100218182458.07c3be6c@redhat.com> <4B7DB6FC.7040900@codemonkey.ws> <4BE3011B.7040001@codemonkey.ws> Date: Fri, 07 May 2010 11:49:42 +0200 In-Reply-To: <4BE3011B.7040001@codemonkey.ws> (Anthony Liguori's message of "Thu, 06 May 2010 12:49:15 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.17 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: Luiz Capitulino Subject: [Qemu-devel] [PATCH] QMP: Add "Downstream extension of QMP" to spec X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Rules for how to extend QMP downstream (if you really have to) without creating interoparability hassles. Signed-off-by: Markus Armbruster --- Aside: * Advice on downstream modifications, items 1. and 2. could use a rationale. * Section '5 Compatibility Considerations' could use some love. QMP/qmp-spec.txt | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 55 insertions(+), 0 deletions(-) diff --git a/QMP/qmp-spec.txt b/QMP/qmp-spec.txt index f3c0327..dc2eb4b 100644 --- a/QMP/qmp-spec.txt +++ b/QMP/qmp-spec.txt @@ -215,3 +215,58 @@ Additionally, Clients must not assume any particular: - Order of json-object members or json-array elements - Amount of errors generated by a command, that is, new errors can be added to any existing command in newer versions of the Server + +6. Downstream extension of QMP +------------------------------ + +We recommend that downstream consumers of QEMU do *not* modify QMP. +Management tools should be able to support both upstream and downstream +versions of QMP without special logic, and downstream extensions are +inherently at odds with that. + +However, we recognize that it is sometimes impossible for downstreams to +avoid modifying QMP. Both upstream and downstream need to take care to +preserve long-term compatibility and interoperability. + +To help with that, QMP reserves JSON object member names beginning with +'__' (double underscore) for downstream use ("downstream names"). This +means upstream will never use any downstream names for its commands, +arguments, errors, asynchronous events, and so forth. + +Any new names downstream wishes to add must begin with '__'. To ensure +compatibility with other downstreams, it is strongly recommended that +you prefix the commands with '__RFQDN_' where RFQDN is a valid, reverse +fully qualified domain name which you control. For example, a qemu-kvm +specific monitor command would be: + + (qemu) __org.linux-kvm_enable_irqchip + +Downstream must not change the server greeting (section 2.2) other than +to offer additional capabilities. But see below for why even that is +discouraged. + +Section '5 Compatibility Considerations' applies to downstream as well +as to upstream, obviously. It follows that downstream must behave +exactly like upstream for any input not containing members with +downstream names ("downstream members"), except it may add members +with downstream names to its output. + +Thus, a client should not be able to distinguish downstream from +upstream as long as it doesn't send input with downstream members, and +properly ignores any downstream members in the output it receives. + +Advice on downstream modifications: + +1. Introducing new commands is okay. If you want to extend an existing + command, consider introducing a new one with the new behaviour + instead. + +2. Introducing new asynchronous messages is okay. If you want to extend + an existing message, consider adding a new one instead. + +3. Introducing new errors for use in new commands is okay. Adding new + errors to existing commands counts as extension, so 1. applies. + +4. New capabilities are strongly discouraged. Capabilities are for + evolving the basic protocol, and multiple diverging basic protocol + dialects are most undesirable.