[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree
Date: Thu, 31 Mar 2016 10:49:44 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]