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 :)? > > 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. > > 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.
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
signature.asc
Description: PGP signature
