qemu-devel
[Top][All Lists]
Advanced

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

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


From: Max Reitz
Subject: Re: [Qemu-devel] [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree
Date: Fri, 1 Apr 2016 17:30:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 31.03.2016 11:49, Stefan Hajnoczi wrote:
> 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?

It's partially in the links I gave above, and partially because I think
such a command would just be nice to have.

The mails linked above concern themselves with getting a list of
children of a quorum node, so I responded that a more general solution
would be nicer.

>          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.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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