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: 2198 bytes --]

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
> 
> 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.
> 
> 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.
> 
> 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 are
> 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 legacy
> 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 that
> the set of nodes thus created may change over time.
> 
> 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 :)?

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