From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akwD2-0006WV-JE for qemu-devel@nongnu.org; Tue, 29 Mar 2016 12:09:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akwCw-0000f9-Sh for qemu-devel@nongnu.org; Tue, 29 Mar 2016 12:09:36 -0400 Date: Tue, 29 Mar 2016 18:09:20 +0200 From: Kevin Wolf Message-ID: <20160329160920.GG4600@noname.redhat.com> References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <20160329155118.GF4600@noname.redhat.com> <56FAA5BB.8030801@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: <56FAA5BB.8030801@redhat.com> Subject: Re: [Qemu-devel] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Markus Armbruster --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 29.03.2016 um 17:56 hat Max Reitz geschrieben: > On 29.03.2016 17:51, Kevin Wolf wrote: > > Am 24.03.2016 um 20:07 hat Max Reitz geschrieben: > >> As I responded to: > >> - http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg04464.html > >> - http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05680.html > >> > >> I think a general solution for querying the block node tree would be > >> nice (I don't think we actually have one). The single patch in this > >> series implements such a command. > >> > >> However, this is an RFC because I'm not sure whether we really want th= is > >> and thus I didn't want to write the necessary tests for something we m= ay > >> be going to discard anyway. > >=20 > > I think we do want to have a way to query the tree structure in QMP. The > > part that I'm so sure about is whether we want a recursive command or > > one that just covers the children of a single node. If we want the > > latter, just adding a children field (which maps role names to node > > names) to query-block might be enough. >=20 > Sounds fine in principle to me, but I'd like to add that I think we may > want to have a new command for querying a specific BDS. You don't get > much choice which nodes you query with query-block, and > query-named-block-nodes seems a bit bloated to me by now... Maybe we need to start over with a new query-block-node command that takes a node name (or BB name as an alias for its root node) and returns information only about that node. That is, it adds node-name support compared to query-block, but it removes the recursive crap for backing files that we added there. > About the "mapping role names to node names" though; I suppose you mean > like { "file": "file-node", "backing": "other-qcow2-node" }. I'd have > loved to do that, but I couldn't imagine a way to represent that in the > QAPI schema. Eric and Markus will tell us, but if nothing else helps: { 'children': 'any' } Kevin --JwB53PgKC5A7+0Ej Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJW+qiwAAoJEH8JsnLIjy/WHIIP+QExCzB/35ghwDpEeQE0eZ3q CMeqD26OZF51E6Zqq2sCyhNM0GYyjJA31EDo4K0IbrufQOlk4xBQlmReW2OeIzlJ 5B1yfRcoaNM5L09nAWh0dk1s7MyKxCfTavcNRe2cH9iVNEVKG9fkhwnDx2dihd/v HkH/JA5gxZY8OwAXMwAyUBK0+LP90GJ0ez2phYhhDJb7q5+TpEYdk8NwgspgkxmE ULys9IIlKb9ALEXXJ23rau1/0dYYDAhAKSGMFXyndW1Rg2eJhSOOeBcaKkaVsQbF kgwKpBiqeiS9dtRvJnvm2VcO8p09p+s5Pczri+WskaIQWH9ECRsGB/IdRDcejTNx kAxkPlScmhPFFK6i9vWfmzj9JwPA2aRofzZ2tQBExv82yZiJtv0nfVBrZuFUIwSL dLpjAsJI4pawg560wd1P2H9bsBxIS+zX8FLwSq+BoWUG/nqBlvJX4HpjCvpb2rno z4z2Ev8tPKS27yH87y3z9iZJRF06daxpU+wIl3O2f34mwmjhVCx9qcM1VVc3cBOz MapFmjldJNmeKQ2k+oJgUWZmryk4PuNQr5QsYa6JqXbUunEYH1AVEt/f18kNdedl CBS3LXnoVCftfmT8s4Xt7hgPgOsOIEa+qutzBEFNSZeIq9+nbaZwOw6U6Ftzqkes w5PS3maWFntcnsk9HXRn =hnDR -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej--