From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alH0o-0000oW-J5 for qemu-devel@nongnu.org; Wed, 30 Mar 2016 10:22:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alH0n-0002Ot-HO for qemu-devel@nongnu.org; Wed, 30 Mar 2016 10:22:22 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> From: Max Reitz Message-ID: <56FBE112.6090207@redhat.com> Date: Wed, 30 Mar 2016 16:22:10 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EJdeubCQJxfNBrMFEbiTWK3EW04MPhpoe" 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: Alberto Garcia , qemu-block@nongnu.org Cc: Kevin Wolf , Markus Armbruster , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EJdeubCQJxfNBrMFEbiTWK3EW04MPhpoe Content-Type: multipart/mixed; boundary="DUojuOf9dOmipT4F0lffOCjJeLh3JcxjV" From: Max Reitz To: Alberto Garcia , qemu-block@nongnu.org Cc: Kevin Wolf , Wen Congyang , Markus Armbruster , qemu-devel@nongnu.org Message-ID: <56FBE112.6090207@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> In-Reply-To: --DUojuOf9dOmipT4F0lffOCjJeLh3JcxjV Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 30.03.2016 14:43, Alberto Garcia wrote: > On Thu 24 Mar 2016 08:07:17 PM CET, Max Reitz wrote: >> 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. >=20 > ...but if the internal representation can change over time, then the > user cannot rely on the output of this command, so what's the use? > Stating that in the command description wouldn't solve anything. That depends. If we know that qemu will never implicitly add anything but single-parent-single-children filters into the chain and we state so, that is something users can work around: If they encounter an unknown node, they just skip down to its child. Alternatively, we could define that for unknown nodes a user wants to skip, they can walk down to the "file" child. So if we state "We do with the graph whatever we want and you get no guarantees whatsoever", that is indeed not very helpful. But if we can give some guarantees, i.e. that qemu will never implicitly remove user-defined nodes and how to behave in case an unknown node is encountered, then it can still be of use. Max --DUojuOf9dOmipT4F0lffOCjJeLh3JcxjV-- --EJdeubCQJxfNBrMFEbiTWK3EW04MPhpoe 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++ESAAoJEDuxQgLoOKytpkkH/j0KSpBbjKtsuiVB+OFzwLVP FF51A+49CDXwhNjxE7g8Va56DhMQVbdvvIl+4YrgVk8CuqHy23D0YRH2agwLofjP DNnSZlcbN8Hl9Je8hkFzeOuHuyGTtXzbqXVopKtIdFSTYKv/+lu+znsKKl7PUh1/ XT32O1Ghgv3zl5M3rrtoEwEYWWp9o99AqL71gIKotIhJYL+EwRNpTV88U3nX61k9 3o9WscrrvnPnjJPX/nnf9fzJy5xo+HQNes7EraCynqSEGp5moww5YqG8QiHw7qWA +djIH2ZoF496LOstd1dSUVURJ0UsEfnb/qRzsHfEVOyKG464Bup06skgopykAXQ= =7vUr -----END PGP SIGNATURE----- --EJdeubCQJxfNBrMFEbiTWK3EW04MPhpoe--