qemu-block
[Top][All Lists]
Advanced

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

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


From: Max Reitz
Subject: Re: [Qemu-block] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree
Date: Tue, 29 Mar 2016 17:43:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

On 29.03.2016 17:39, Eric Blake wrote:
> On 03/29/2016 09:29 AM, Max Reitz wrote:
> 
>>
>> In my opinion, the way the order is explicitly represented is through
>> every child's role. For quorum, "children.${i}" comes before
>> "children.${i+1}".
>>
>> The general block layer does not care about these generic children, it
>> only cares about "file" and "backing". Therefore, it cannot know the
>> order of the children (if there is any) and it in fact does not care. If
>> there is an order, we would thus need to get the block driver to define
>> it and I don't think that's trivial (the easiest way to do so probably
>> is to define a driver-supplied iterator function).
>>
>> Note that any order of children would be driver-specific still, just as
>> generic children's role names are driver-specific. Therefore, if a user
>> knows how to interpret the order of children, they'd know how to derive
>> the order from the role name, too.
> 
> That argument is reasonable - either a callback so that a driver can
> emit children in the order it desires, or else the documentation that if
> order matters, the user must be able to reconstruct order based on
> information already present without having to rely on the array being sored.
> 
>>
>> Also noteworthy is that it's completely fine to leave the order
>> undefined for now and implement functionality to sort the array at some
>> later point in time.
> 
> That's harder - it's not easy to introspect whether output will be
> sorted or not, so clients would always have to treat the data as
> unsorted, at which point adding sorting later doesn't help.  Sorting is
> only useful to add up front, where you can document it as part of the
> contract; so now the question is whether sorting is useful enough to
> worry about making it part of the contract.

Well, we can make it introspectable, it will just be a bit ugly. For
instance, just adding a "sorted" boolean would solve that issue. It's
ugly but it's not as if it would actually hurt anybody.

The only result would be that we should not return a BlockNodeTreeNode
directly but a more complex structure which then contains the root
BlockNodeTreeNode and may contain more information about the tree in the
future (e.g. the "sorted" boolean).

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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