From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvnj-0008QX-66 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:43:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvni-0000yg-4R for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:43:27 -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> <56FAA19D.4090802@redhat.com> From: Max Reitz Message-ID: <56FAA296.8000006@redhat.com> Date: Tue, 29 Mar 2016 17:43:18 +0200 MIME-Version: 1.0 In-Reply-To: <56FAA19D.4090802@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0o5OjVN9hgLp4V1UjuFJawVFmCFR0nPTu" 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: Eric Blake , 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) --0o5OjVN9hgLp4V1UjuFJawVFmCFR0nPTu Content-Type: multipart/mixed; boundary="S5WDfnHnkM0a8GEuwt4E7eWuh10TUiDxQ" From: Max Reitz To: Eric Blake , Wen Congyang , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, Kevin Wolf , Markus Armbruster Message-ID: <56FAA296.8000006@redhat.com> Subject: Re: [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree 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> <56FAA19D.4090802@redhat.com> In-Reply-To: <56FAA19D.4090802@redhat.com> --S5WDfnHnkM0a8GEuwt4E7eWuh10TUiDxQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.03.2016 17:39, Eric Blake wrote: > 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}". >> >> 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 defin= e >> 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 a= s >> generic children's role names are driver-specific. Therefore, if a use= r >> knows how to interpret the order of children, they'd know how to deriv= e >> the order from the role name, too. >=20 > That argument is reasonable - either a callback so that a driver can > emit children in the order it desires, or else the documentation that i= f > order matters, the user must be able to reconstruct order based on > information already present without having to rely on the array being s= ored. >=20 >> >> Also noteworthy is that it's completely fine to leave the order >> undefined for now and implement functionality to sort the array at som= e >> later point in time. >=20 > 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 --S5WDfnHnkM0a8GEuwt4E7eWuh10TUiDxQ-- --0o5OjVN9hgLp4V1UjuFJawVFmCFR0nPTu 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 iQEcBAEBCAAGBQJW+qKWAAoJEDuxQgLoOKyt8QwH/RTjK8Hs0odfvIV3S2lE48j/ qzxFH4GUQCyLRF6hIIWye26xNSHnpPVoz82N8jWaYFWvwuklmtaGhN4sWscX9D53 Mf8GjkkGGvO3X9eHLScjjyldzIK9TwXSFjf0r/DCUW7/EiedbRJI+ujZ8IUPxwmH NOYljYC9cyZC0QeVFE7hoRU0wXhWQHH78iFz0VQ3ggEsNgtx74mtAQ3iVpU2ucqk o46B52YjQtt62XSG8OTetNOWZJUHP75Z+GNnySlprymj2qEHejiH+Za2dJOgvVcM dW5NVWwDnDNSN/l/GYTWNj7zgungpPKQUbc1ZV8dklheWBV9O3Pp/dnNx77EDR0= =oRzB -----END PGP SIGNATURE----- --0o5OjVN9hgLp4V1UjuFJawVFmCFR0nPTu--