From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw2rT-0007X6-SJ for qemu-devel@nongnu.org; Wed, 03 Dec 2014 00:52:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xw2rN-0007nP-M3 for qemu-devel@nongnu.org; Wed, 03 Dec 2014 00:52:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw2rN-0007m3-E7 for qemu-devel@nongnu.org; Wed, 03 Dec 2014 00:52:21 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB35qJb7024165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Dec 2014 00:52:19 -0500 Date: Wed, 3 Dec 2014 13:52:16 +0800 From: Fam Zheng Message-ID: <20141203055144.GA1179@ad.nay.redhat.com> References: <87vbltvpl0.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vbltvpl0.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] Review of monitor commands identifying BDS / BB by name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On Tue, 12/02 20:06, Markus Armbruster wrote: > == block-core.json == > > * block-commit > > @device names a backend, @top and @base each name one of its nodes via > file name matching. > > TODO: support specifying the two nodes via node name. > > Why do we need @device when a top node is specified? > > * We currently need the backend to set op blockers, and finding a > node's backend isn't easy. Implementation detail shows through the > interface, blech. > > * We need to know whether the top node is the active layer. > > Complication: if it's shared by multiple backends, it may be the > active layer in one but not the other. Specifying the backend > resolves the ambiguity. Whether that makes sense I don't know. > > * block-stream > > @device names a backend, @base names a node via file name matching. > > TODO: support specifying the node via node name. > > I think backend is inappropriate here, we should support streaming up > to a node, just like block-commit supports committing down from a > node. Agreed. > > * block_passwd > * block_resize > > @node-name names a node. > > @device names a backend, and references its root node, for > compatibility. > > Either @device or @node-name must be given. > > TODO: should have single mandatory parameter instead of two optionals. > > * blockdev-snapshot-sync > > @node-name and @device as for block_passwd, including TODO. > > @snapshot-node-name defines the new node's node name. > > * block_set_io_throttle > > @device names a backend. > > TODO: support nodes. > > Note: we'd like to redo throttling as a block filter node, so maybe > we'll have a completely different command instead. Whether it's implemented in core block layer or as a block filter node is implementation detail from user's PoV, so it shouldn't matter unless we use a "general" block filter configuration command. > > * blockdev-add > > This command defines a backend and its node tree, where sub-trees may > be references to existing nodes. > > @id defines the backend's name. > > @node-name defines its root node's node name. > > Note: blockdev-add always defines a backend. When you build up a > backend bottom-up with several commands, you get a bunch of unwanted > backends "in the middle". I'd like to make @id optional, and omit the > backend when it's missing. > > * change-backing-file > > @device names a backend, @image-node-name names a node. > > As far as I can tell, we need the backend only to set op blockers. > Implementation detail shows through the interface. > > * drive-backup > > @device names a backend. > > Do we want to be able to back up any node, or only a backend? > > Note: documentation of @target sounds like it could somehow name a > backend, but as far as I can tell it's always interpreted as file > name. > > * drive-mirror > > @device names a backend, @replaces names a node, and @node-name > defines the name of the new node. > > Do we want to be able to mirror any node, or only a backend? > > Note: documentation of @target sounds like it could somehow name a > backend, but as far as I can tell it's always interpreted as file > name. > > Note: drive-mirror supports @replaces, but drive-backup doesn't. Odd. It's only asymmetric, not odd: @target has the same data in drive-mirror, so "replaces" doesn't surprise @device's user. That's not true for drive-backup. > * query-blockstats > > Returns some stats for all backends as array of BlockStats. > BlockStats member @device is the backend name. Member @stats contains > the stats for the backend's root node. Member @parent is BlockStats > for the child node that is stored in BDS member file. Member @backing > is BlockStats for the chold node that is stored in BDS member > backing_hd. Stats for other children aren't returned. > > TODO: generalize this to the full tree, include node names. > > * query-block-jobs > > Returns information on block jobs as array of BlockJobInfo. A block > job is always tied to a backend, and BlockJobInfo member @device is > its name. > > The question whether we need a node name here is moot; see > block-job-cancel above. > We are not internally ready to untie block job from backend yet, once we get there, we should start giving names to block jobs, add support some kind of default naming/querying to be backward compatible. Fam