From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajr9h-0007Ly-8D for qemu-devel@nongnu.org; Sat, 26 Mar 2016 12:33:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajr9g-0006eq-Bp for qemu-devel@nongnu.org; Sat, 26 Mar 2016 12:33:41 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <1458846438-28573-2-git-send-email-mreitz@redhat.com> <56F4E0C0.6080609@cn.fujitsu.com> From: Max Reitz Message-ID: <56F6B9DA.1090601@redhat.com> Date: Sat, 26 Mar 2016 17:33:30 +0100 MIME-Version: 1.0 In-Reply-To: <56F4E0C0.6080609@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="glUhvU5eqdvPBSkA0CGPpXGtwhLUadp1b" Subject: Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang , qemu-block@nongnu.org Cc: Kevin Wolf , qemu-devel@nongnu.org, Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --glUhvU5eqdvPBSkA0CGPpXGtwhLUadp1b Content-Type: multipart/mixed; boundary="GL5tLkvsc2b57BWPONdUHCUgmheXrc8h3" From: Max Reitz To: Wen Congyang , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, Kevin Wolf , Eric Blake , Markus Armbruster Message-ID: <56F6B9DA.1090601@redhat.com> Subject: Re: [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <1458846438-28573-2-git-send-email-mreitz@redhat.com> <56F4E0C0.6080609@cn.fujitsu.com> In-Reply-To: <56F4E0C0.6080609@cn.fujitsu.com> --GL5tLkvsc2b57BWPONdUHCUgmheXrc8h3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 25.03.2016 07:54, Wen Congyang wrote: > On 03/25/2016 03:07 AM, Max Reitz wrote: >> This command returns the tree of BlockDriverStates under a given root >> node. >> >> Every tree node is described by its node name and the connection of a >> parent node to its children additionally contains the role the child >> assumes. >> >> A node's name can then be used e.g. in conjunction with >> query-named-block-nodes to get more information about the node. >=20 > I found another problem: >=20 > {'execute': 'query-block-node-tree', 'arguments': {'root-node': 'disk1'= } } > {"return": {"children": [{"role": "children.1", "node": {"children": [{= "role": "file", "node": {}}], "node-name": "test1"}}, {"role": "children.= 0", "node": {"children": [{"role": "file", "node": {}}]}}]}} >=20 > s->children[0] is children.0, and s->children[1] is children.1. > But we output them in reverse order. The reason is: >=20 > BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs, > BlockDriverState *child_bs, > const char *child_name, > const BdrvChildRole *child_role) > { > BdrvChild *child =3D bdrv_root_attach_child(child_bs, child_name, c= hild_role); > QLIST_INSERT_HEAD(&parent_bs->children, child, next); > return child; > } >=20 > We insert the new child to the head, not the tail... Well, the idea is that the order of children doesn't really matter; The only thing that describes the behavior of a child is its role. For instance, for qcow2 it doesn't matter whether the "file" or the "backing" BDS is the first child. However, for quorum, the order might matter (e.g. in FIFO mode). But then again, the order is clearly specified by the role again: The first child is the one with the "children.0" role. So I don't think this is real problem as long as I add a note to the documentation that the order of objects in the @children array is undefined and does not have any significance. Max --GL5tLkvsc2b57BWPONdUHCUgmheXrc8h3-- --glUhvU5eqdvPBSkA0CGPpXGtwhLUadp1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW9rnaAAoJEDuxQgLoOKyt0MIH/3xykDjvbBQXTu9eXXzVPe1m w39NRo6ChK+4Gq3aU25u1KVhtDBDXKIQ4tw0RJh4Y7umrf2Ldg1kNkXcYa/VTN4h EuLg72STkfWqwk73uXOLoY7OFDXSUKABUgBFrHJO2lAvlA7AS4Nh0a4IyKt76L9/ zdHVyxo9K/vUbajrhLJaxUa6Rx9YRd9r7v8uqI7PBoW/619BXfR2Dfvm8gpMe3ly Kb05KWuYotWuuNDxAog9vLkmHB7MxMcj7Bfj4d8n29ooaGsDlefiGEmL93S6tNo3 shjT5Lak6E9m4YL6A7QAqF8Ul9ngnFjbG/DOaUbjR7q3jNiFB61HhW8q5bOoEDo= =yAmQ -----END PGP SIGNATURE----- --glUhvU5eqdvPBSkA0CGPpXGtwhLUadp1b--