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

[Max Reitz <mreitz@redhat.com>]

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]