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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2046 bytes --]

On 30.03.2016 14:43, Alberto Garcia wrote:
> On Thu 24 Mar 2016 08:07:17 PM CET, Max Reitz wrote:
>> 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.
> 
> ...but if the internal representation can change over time, then the
> user cannot rely on the output of this command, so what's the use?
> Stating that in the command description wouldn't solve anything.

That depends. If we know that qemu will never implicitly add anything
but single-parent-single-children filters into the chain and we state
so, that is something users can work around: If they encounter an
unknown node, they just skip down to its child.

Alternatively, we could define that for unknown nodes a user wants to
skip, they can walk down to the "file" child.

So if we state "We do with the graph whatever we want and you get no
guarantees whatsoever", that is indeed not very helpful. But if we can
give some guarantees, i.e. that qemu will never implicitly remove
user-defined nodes and how to behave in case an unknown node is
encountered, then it can still be of use.

Max


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