Re: [Qemu-devel] [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]