[Top][All Lists]

[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: Eric Blake
Subject: Re: [Qemu-block] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree
Date: Tue, 29 Mar 2016 09:39:09 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

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.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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