From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajr3Z-00061r-AA for qemu-devel@nongnu.org; Sat, 26 Mar 2016 12:27:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajr3Y-00058J-Aq for qemu-devel@nongnu.org; Sat, 26 Mar 2016 12:27:21 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <1458846438-28573-2-git-send-email-mreitz@redhat.com> <56F4A790.4020609@cn.fujitsu.com> From: Max Reitz Message-ID: <56F6B85F.2090501@redhat.com> Date: Sat, 26 Mar 2016 17:27:11 +0100 MIME-Version: 1.0 In-Reply-To: <56F4A790.4020609@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qnEDH6NoNQnk81rsNPfpFuNTmNkjOQLDT" 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) --qnEDH6NoNQnk81rsNPfpFuNTmNkjOQLDT Content-Type: multipart/mixed; boundary="FuvkrUtBoLGXcfX3SBPUlWK4XRvSxVBDf" From: Max Reitz To: Wen Congyang , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, Kevin Wolf , Eric Blake , Markus Armbruster Message-ID: <56F6B85F.2090501@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> <56F4A790.4020609@cn.fujitsu.com> In-Reply-To: <56F4A790.4020609@cn.fujitsu.com> --FuvkrUtBoLGXcfX3SBPUlWK4XRvSxVBDf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 25.03.2016 03:50, 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 test this patch, and it works. > {'execute': 'query-block-node-tree', 'arguments': {'root-node': 'disk1'= } } > {"return": {"children": [{"role": "children.0", "node": {"children": [{= "role": "file", "node": {"children": [], "node-name": "#block175"}}], "no= de-name": "#block267"}}], "node-name": "#block040"}} >=20 > Shoule we hide the node name like "#blockxxx"? No, I don't think so. In fact I was thinking of making the node name non-optional because every BDS should have one due to these auto-generated ones. > If the bs doesn't have any child, should we output: '"children": [], '?= Omitting an empty array (thus making the @children key optional) occurred to me, too. I didn't find any strong reason to do so, however. It makes generating the output a bit more complicated and may also make parsing it just a tiny bit more complicated. I think that omitting it would make more sense to a human reader, but QMP is a machine protocol, so this is not a very strong argument. So all in all I saw neither strong arguments to omit an empty array nor to include it. Thus I included it because that makes the code simpler. > Can we add a new parameter: depth? For example, If I only want to know = the quorum's > child name, we can limit the depth, and the output may be very clear. Good idea. I can do so in the next version, but first I'd like to hear more opinions on what other people think of this command. If they think it's fine, I'll include a depth parameter. Thank you for you comments! Max --FuvkrUtBoLGXcfX3SBPUlWK4XRvSxVBDf-- --qnEDH6NoNQnk81rsNPfpFuNTmNkjOQLDT 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 iQEcBAEBCAAGBQJW9rhfAAoJEDuxQgLoOKytOEYH/jfHONvycv7Pxw0yiRY1DXzy gVpGTguu8yPFI7REs7mps+gL+f7UOtauqxKashZpAiFuWadC9AIo/rSwwf1x1iDX nKRkALZBn3sQmYvRxaw/k5XExYjQNnxIDCB9G4sIfGP8D1Wl4tZX4Eoz4EMEQ8Oq 85RKpDYHQofUwQH9Hrrt8Q34SsJO59G9WvHzRB53FDjse101JwWB0gzdB2ffwKJf dUf+cWnfDlAiS1fpdbnnYyaEbjQLpzRa7JJmym8eofS/hycL2UXuVCYMHwt2EIP2 1BRL+98yXwp50K7CpFD7YEX9SvBrjO6gXQuvjHvU/j9XO0Fd/wW0k6BW70bH7Cc= =iU5d -----END PGP SIGNATURE----- --qnEDH6NoNQnk81rsNPfpFuNTmNkjOQLDT--