From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>,
Wen Congyang <wency@cn.fujitsu.com>,
qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
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 [thread overview]
Message-ID: <56FAA19D.4090802@redhat.com> (raw)
In-Reply-To: <56FA9F4E.2030806@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-03-29 15:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 19:07 [Qemu-devel] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree Max Reitz
2016-03-24 19:07 ` [Qemu-devel] [RFC for-2.7 1/1] " Max Reitz
2016-03-25 2:50 ` Wen Congyang
2016-03-26 16:27 ` Max Reitz
2016-03-25 6:54 ` Wen Congyang
2016-03-26 16:33 ` Max Reitz
2016-03-28 15:25 ` Eric Blake
2016-03-29 15:29 ` Max Reitz
2016-03-29 15:39 ` Eric Blake [this message]
2016-03-29 15:43 ` Max Reitz
2016-03-29 15:51 ` [Qemu-devel] [RFC for-2.7 0/1] " Kevin Wolf
2016-03-29 15:56 ` Max Reitz
2016-03-29 16:09 ` Kevin Wolf
2016-03-29 16:10 ` Max Reitz
2016-03-30 12:43 ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2016-03-30 14:22 ` Max Reitz
2016-03-31 9:49 ` Stefan Hajnoczi
2016-04-01 15:30 ` Max Reitz
2016-04-04 12:35 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FAA19D.4090802@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wency@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).