From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y22HC-0004cV-F7 for qemu-devel@nongnu.org; Fri, 19 Dec 2014 13:27:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y22H6-0005E9-9q for qemu-devel@nongnu.org; Fri, 19 Dec 2014 13:27:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y22H6-0005E1-2J for qemu-devel@nongnu.org; Fri, 19 Dec 2014 13:27:40 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBJIRdoP001029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 19 Dec 2014 13:27:39 -0500 From: Markus Armbruster References: <87vbltvpl0.fsf@blackfin.pond.sub.org> <87zjan1n11.fsf@blackfin.pond.sub.org> Date: Fri, 19 Dec 2014 19:27:36 +0100 In-Reply-To: <87zjan1n11.fsf@blackfin.pond.sub.org> (Markus Armbruster's message of "Tue, 16 Dec 2014 19:12:58 +0100") Message-ID: <87lhm3sdev.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Can we make monitor commands identify BDS / BB by name consistently? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , John Snow , Fam Zheng , Stefan Hajnoczi Markus Armbruster writes: > Conscious design decision: Backend (BB) and node (BDS) names share a > common name space. > > Enables a convenience feature: when a command needs a node, we accept > either kind of name, and a backend name is resolved to its root node. > > Should not be confused with a command that can work either on a backend > or on a node. There, a backend name resolves to the backend, not its > root node. Can't point to an example offhand. > > Let's concentrate on the "command needs a node" case. > > As we saw in my review of monitor commands, we have two different > conventions there. > > * Single name > > Within BlockdevOptions objects (used by blockdev-add), we use a single > string member, with a name that explains its role. Actually, the > member is an anonymous union of string and BlockdevOptions. > > Example: a BlockdevOptionsGenericFormat object (used for format "raw" > and others) has a member @file that may name a backend or a node. > > Example: a BlockdevOptionsQcow2 object (used for "qcow2"), has a > member @file as above, and a member @backing that may again name a > backend or a node. > > * Pair of names > > Elsewhere, command argument objects have a pair of optional members, > of which exactly one must be present. One of them must name a > backend, the other must name a node. The former is commonly called > @device, the latter @node-name. > > Example: block_passwd parameters @device and @node-name. > > I'd very much like some consistency here. > > As Kevin pointed out, you can't easily change BlockdevOptions to the > "pair of names" convention, because an anonymous union can have only one > object member, and that's taken by BlockdevOptions. If you want us to > adopt the "pair of names" convention, you need to come up with a way to > use it with BlockdevOptions. > > I want us to adopt the "single name" convention instead. Therefore, I > need to come up with a way to use it with the command argument objects > that currently use "pair of names". The problems there are > compatibility and discoverability. [Text on how to solve them snipped...] John Snow pointed out to me that we still haven't spelled out how this single parameter should be named. On obvious option is calling it node-name, or FOO-node-name when we have several. However, we'd then have two subtly different kinds of parameters called like that: the old ones accept *only* node names, the new ones also accept backend names, which automatically resolve to the backend's root node. Three ways to cope with that: * Find a better name. * Make the old ones accept backend names, too. Only a few, not that much work. However, there are exceptions: - blockdev-add's node-name *defines* the node name. - query-named-block-nodes's node-name *is* the node's name. * Stop worrying and embrace the inconsistency. The affected commands are headed for deprecation anyway. I think I'd go with "node" or "FOO-node" for parameters that reference nodes and accept both node names and backend names, and refrain from touching the existing node-name parameters. Opinions?