qemu-devel
[Top][All Lists]
Advanced

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

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


From: Max Reitz
Subject: Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree
Date: Sat, 26 Mar 2016 17:33:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

On 25.03.2016 07:54, Wen Congyang wrote:
> On 03/25/2016 03:07 AM, Max Reitz wrote:
>> This command returns the tree of BlockDriverStates under a given root
>> node.
>>
>> Every tree node is described by its node name and the connection of a
>> parent node to its children additionally contains the role the child
>> assumes.
>>
>> A node's name can then be used e.g. in conjunction with
>> query-named-block-nodes to get more information about the node.
> 
> I found another problem:
> 
> {'execute': 'query-block-node-tree', 'arguments': {'root-node': 'disk1' } }
> {"return": {"children": [{"role": "children.1", "node": {"children": 
> [{"role": "file", "node": {}}], "node-name": "test1"}}, {"role": 
> "children.0", "node": {"children": [{"role": "file", "node": {}}]}}]}}
> 
> s->children[0] is children.0, and s->children[1] is children.1.
> But we output them in reverse order. The reason is:
> 
> BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs,
>                              BlockDriverState *child_bs,
>                              const char *child_name,
>                              const BdrvChildRole *child_role)
> {
>     BdrvChild *child = bdrv_root_attach_child(child_bs, child_name, 
> child_role);
>     QLIST_INSERT_HEAD(&parent_bs->children, child, next);
>     return child;
> }
> 
> We insert the new child to the head, not the tail...

Well, the idea is that the order of children doesn't really matter; The
only thing that describes the behavior of a child is its role. For
instance, for qcow2 it doesn't matter whether the "file" or the
"backing" BDS is the first child.

However, for quorum, the order might matter (e.g. in FIFO mode). But
then again, the order is clearly specified by the role again: The first
child is the one with the "children.0" role.

So I don't think this is real problem as long as I add a note to the
documentation that the order of objects in the @children array is
undefined and does not have any significance.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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