From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am12U-0005JD-Ex for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:31:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am12S-0007Zz-Qj for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:31:10 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <20160331094944.GA20286@stefanha-x1.localdomain> From: Max Reitz Message-ID: <56FE9432.6020905@redhat.com> Date: Fri, 1 Apr 2016 17:30:58 +0200 MIME-Version: 1.0 In-Reply-To: <20160331094944.GA20286@stefanha-x1.localdomain> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AMl2To9RDwB3Gbgfvx5DCtLSot23WJktB" Subject: Re: [Qemu-devel] [Qemu-block] [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: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AMl2To9RDwB3Gbgfvx5DCtLSot23WJktB Content-Type: multipart/mixed; boundary="IrHlHWuV904BqRHtt9FRARkuq6lExSar8" From: Max Reitz To: Stefan Hajnoczi Cc: qemu-block@nongnu.org, Kevin Wolf , Wen Congyang , Markus Armbruster , qemu-devel@nongnu.org Message-ID: <56FE9432.6020905@redhat.com> Subject: Re: [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <20160331094944.GA20286@stefanha-x1.localdomain> In-Reply-To: <20160331094944.GA20286@stefanha-x1.localdomain> --IrHlHWuV904BqRHtt9FRARkuq6lExSar8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31.03.2016 11:49, Stefan Hajnoczi wrote: > On Thu, Mar 24, 2016 at 08:07:17PM +0100, Max Reitz wrote: >> As I responded to: >> - http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg04464.htm= l >> - http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05680.htm= l >> >> 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. >> >> There are two reasons why I fear we may not want this: >> >> The first is that the node graph is more or less something internal to= >> qemu. Its actual structure may (and most probably will) change over >> time. We do want to be able to let the user or management application >> manage the graph in fine detail, but these modifications are something= >> that can be emulated by legacy handling code later if we decide they a= re >> no longer in line with the internal graph that we'd like to have. >> >> However, if we emit the full graph with a command such as introduced >> here, we can hardly change its outside appearance just to please legac= y >> applications. The output will change if the internal representation >> changes. >> >> I don't personally think this is too bad as long as we clearly state >> this in the command's description: That qemu is free to implicitly >> create intermediate nodes the user did not explicitly specify, and tha= t >> the set of nodes thus created may change over time. >> >> No, I didn't specify this in this version, but it's an RFC, after all.= >> :-) >=20 > I'm also concerned about exposing the graph since QEMU may implement > features with internal block filters (I/O throttling, backup block job > to get rid of write notifiers, etc). These nodes come and go depending= > on high-level commands issued by the guest *and* are dependent on the > QEMU version. >=20 > What is the purpose of this command - I didn't see that in your cover > letter? It's partially in the links I gave above, and partially because I think such a command would just be nice to have. The mails linked above concern themselves with getting a list of children of a quorum node, so I responded that a more general solution would be nicer. > Does it still serve its purpose if we warn the user that the > graph structure can contain little surprises :)? As I replied to Berto, I think we can come up with some constraints about what qemu may do and what it will not do. That way, we will keep the flexibility we need and users can still get the information they want= =2E For instance, I proposed that qemu will never remove explicitly created nodes but may always implicitly add nodes. If a user thus encounters an unknown and/or unexpected node, it should just skip the node and fall through to its "file" child. I think that fact that implicitly created nodes will always be inserted into edges in the BDS graph such that the edge's child will be the node's "file" child is something we are able to guarantee. Max --IrHlHWuV904BqRHtt9FRARkuq6lExSar8-- --AMl2To9RDwB3Gbgfvx5DCtLSot23WJktB 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 iQEcBAEBCAAGBQJW/pQzAAoJEDuxQgLoOKytb+YH/0jWHBpI15SMsXIgkXVF031u MQpN/LQ6fCgqlrj+BTi9/t96c9sMlSg9qys+7t9EIq1A9IBhD4UgXONsVELQt/Ta wY1jdmZ3RO6AlEUCHaaY2J3JwsOOabO8CoebfmvnPW+T/9qFhWaurikzJqWNGrfb ovZY35tYJ+h/lu0F+mkhFtx0EGhV/zGNgU868pRqzZ7nooH26t6Jo49Kunou8ktd hvfGuWP3IaL37sKhCNm1v1xvKtt+erCuXTIfBeo5FRVLVX9ardsQnH6F1vVCXSC3 tr1VWayManx3pLEYRhMywCOlSec8M1eQHHIwINa9XBf6q/tpxmBx3jlIfGYGtgE= =Y4Ae -----END PGP SIGNATURE----- --AMl2To9RDwB3Gbgfvx5DCtLSot23WJktB--