[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: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [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
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree, Kevin Wolf, 2016/03/29
Re: [Qemu-devel] [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree, Alberto Garcia, 2016/03/30
Re: [Qemu-devel] [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree, Stefan Hajnoczi, 2016/03/31