From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvjg-0002DM-TZ for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:39:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvjf-0007RL-LF for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:39:16 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <1458846438-28573-2-git-send-email-mreitz@redhat.com> <56F4E0C0.6080609@cn.fujitsu.com> <56F6B9DA.1090601@redhat.com> <56F94CD3.5010608@redhat.com> <56FA9F4E.2030806@redhat.com> From: Eric Blake Message-ID: <56FAA19D.4090802@redhat.com> Date: Tue, 29 Mar 2016 09:39:09 -0600 MIME-Version: 1.0 In-Reply-To: <56FA9F4E.2030806@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f8IFfobahXi52NwxBDKP1BEHWvFuuIOIt" Subject: Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Wen Congyang , qemu-block@nongnu.org Cc: Kevin Wolf , qemu-devel@nongnu.org, Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f8IFfobahXi52NwxBDKP1BEHWvFuuIOIt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2016 09:29 AM, Max Reitz wrote: >=20 > 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}". >=20 > 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. I= f > 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). >=20 > 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 sor= ed. >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --f8IFfobahXi52NwxBDKP1BEHWvFuuIOIt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW+qGdAAoJEKeha0olJ0Nq/rsH/0TovW4TbhDT4YlYrQafEnNe lLNEKbGtw4BZNR+th2m9dEJzUH5fqMch5eAyypOUWw7oEL/jDuD80gtaSX9wNRKj raotDxsQTrAB7JYY6JHsaZnFqpuyaRK39yDWd1LtBVkecvx1RpgNHBhIYYrLhETI rGKrOaRehaY65+tYVZp4KJHbCb2V8xExS1IopzetJAgZt4iN1YAFZ7OUNrWaHqXH ZlkM3OieXWQVG6F7UUXuALK5Oy46xlvV6YI1VJz8O88bK3fxxGIt+dDeohPtFfuj P/2ndmIyoz1UPHKF8y2GSGKieOkZ00ctKyN0sqM2n/tJrKrS986yGu71NTAMOCk= =I0Z8 -----END PGP SIGNATURE----- --f8IFfobahXi52NwxBDKP1BEHWvFuuIOIt--