From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an3iy-0002gT-Dk for qemu-devel@nongnu.org; Mon, 04 Apr 2016 08:35:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an3ix-0001hG-GR for qemu-devel@nongnu.org; Mon, 04 Apr 2016 08:35:20 -0400 Date: Mon, 4 Apr 2016 13:35:08 +0100 From: Stefan Hajnoczi Message-ID: <20160404123508.GA13632@stefanha-x1.localdomain> References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <20160331094944.GA20286@stefanha-x1.localdomain> <56FE9432.6020905@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <56FE9432.6020905@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 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 01, 2016 at 05:30:58PM +0200, Max Reitz wrote: > > Does it still serve its purpose if we warn the user that the > > graph structure can contain little surprises :)? >=20 > 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. >=20 > 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. >=20 > 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. Another option would be for nodes to have a child alias that dumb clients use when skipping the node. This way we're not tied to actually implementing it with bs->file. One thing we must be careful about is to avoid using parent->child relationships in QMP APIs because they introduce race conditions: Imagine a block job that inserts a filter node. If the client wishes to insert its own node below the filter node we must solve the following race condition. The client queries the block graph and traverses to find the parent node. Now it issues a QMP command to insert its node below the parent. If the block job happens to complete right before the QMP command is processed, there will be an error because the parent node no longer exists. The race conditions must be kept in mind for all APIs we design once we begin exposing the block graph :(. I would say it's an error for the client to refer to internal nodes. QEMU shouldn't allow the client to name internal nodes due to the race condition issue. Perhaps they shouldn't have an externally visible node ID/name at all. Stefan --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXAl98AAoJEJykq7OBq3PIFQgIAI1WEINhhq7NMSi/9y7MRdgq tL/4R0JYOtUAQYuxSaZfmVQy+N+12xumhs0XnaOUeNOoge2iP6LcdFiAS6Wwof3D S11/LGAoJzKdEK1NyAmaQUO+HR2iybure0kEF0fkwzim1OF4ZawnKR5hpCblG5fu WN0AqJF/ooxl/YVQYxkgZ/DZmts/jpiI00+3iH4JvcFYWl7Ogn8h42BiIe6CsMUp PF9uOV19lMnECiPE3tRuiX9st84ZZ/sTX05d3h4I+jaYogX2PSnTT08c7TahN+VW UPfeGoYMIldDFWa2SDQYpMpGFEDmZAR9HbhV4dc4jAWHWmf6gArdPdRRUxJFG6o= =HAse -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--