From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alZEe-0006Lc-Q0 for qemu-devel@nongnu.org; Thu, 31 Mar 2016 05:49:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alZEd-0004gR-NN for qemu-devel@nongnu.org; Thu, 31 Mar 2016 05:49:52 -0400 Date: Thu, 31 Mar 2016 10:49:44 +0100 From: Stefan Hajnoczi Message-ID: <20160331094944.GA20286@stefanha-x1.localdomain> References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <1458846438-28573-1-git-send-email-mreitz@redhat.com> 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: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, Markus Armbruster --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.html > - http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05680.html >=20 > 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. >=20 > However, this is an RFC because I'm not sure whether we really want this > and thus I didn't want to write the necessary tests for something we may > be going to discard anyway. >=20 > There are two reasons why I fear we may not want this: >=20 > 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 are > no longer in line with the internal graph that we'd like to have. >=20 > However, if we emit the full graph with a command such as introduced > here, we can hardly change its outside appearance just to please legacy > applications. The output will change if the internal representation > changes. >=20 > 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 that > the set of nodes thus created may change over time. >=20 > No, I didn't specify this in this version, but it's an RFC, after all. > :-) 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. What is the purpose of this command - I didn't see that in your cover letter? Does it still serve its purpose if we warn the user that the graph structure can contain little surprises :)? --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJW/PK4AAoJEJykq7OBq3PIPc4H/Rq6rCHlKylsmNXu5h+OKoWb G5A6DP7jxCF2vcRsFm/bVAEDhu9slUh5IOCMUTD4ICCvMeRZsLM2ujTYCzUOLHvX mit4Git7VXn8MiWnNMlKBmMJ4Ee7/II2UMmVshzECUeZ/yWHGmoKIQJzw2fbL6Hs vCnete21TFm699wcV6Pw/5ofNB0RqKjfgK1I7Dxj7WcRkSmZGmZz6LOnA1EfQ1hq pJFo6Hi2b+79jGov6Be/DcH3/sLEuo6mGfxWJLmEQ20ZfsW0p5h9Ljj9fzaYLbG1 Udf3Wi4rMnaTwEkUYcKhId3ALPkeUnb05q1Jewgp0WNb557n599wYIeBLqE9KIw= =H4tB -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--