From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvvZ-0005pU-8c for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:51:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvvW-0003QL-26 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:51:33 -0400 References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> From: Max Reitz Message-ID: <56FAA47A.2020801@redhat.com> Date: Tue, 29 Mar 2016 17:51:22 +0200 MIME-Version: 1.0 In-Reply-To: <56FAA2C4.3000002@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Rgws7DHOnnFoMTQtlqP4CnB5iH43gssMr" Subject: Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Kevin Wolf , Changlong Xie , Alberto Garcia , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Markus Armbruster , Gonglei , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rgws7DHOnnFoMTQtlqP4CnB5iH43gssMr Content-Type: multipart/mixed; boundary="8rcqTlLcAOPhMm09BRE8BCkw8vNhIr4Ui" From: Max Reitz To: Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Alberto Garcia , Changlong Xie , qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <56FAA47A.2020801@redhat.com> Subject: Re: [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> In-Reply-To: <56FAA2C4.3000002@redhat.com> --8rcqTlLcAOPhMm09BRE8BCkw8vNhIr4Ui Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.03.2016 17:44, Eric Blake wrote: > On 03/29/2016 09:38 AM, Max Reitz wrote: >> On 17.03.2016 10:56, Wen Congyang wrote: >>> On 03/17/2016 05:48 PM, Dr. David Alan Gilbert wrote: >> >> [...] >> >>>> The children.0 notation is really confusing in the way that Berto >>>> describes; I hit this a couple of months ago and it really doesn't >>>> make sense. >>> >>> Do you mean: read from children.1 first, and then read from children.= 0 in >>> fifo mode? Yes, the behavior is very strange. >> >> So is this intended or is it not? In >> http://lists.nongnu.org/archive/html/qemu-block/2016-03/msg00526.html >> you said that it is. >> >> I myself would indeed say it is very strange. If I were a user, I woul= d >> not expect this behavior. And as I developer, I think that how a BDS's= >> child is used by its parent should solely depend on its role (e.g. >> whether it is "children.0" or "children.1"). >=20 > It sounds like the argument here, and in Max's thread on > query-block-node-tree, is that we DO have cases where order matters, an= d > so we need a way for the hot-add operation to explicitly specify where > in the list a child is inserted (whether it is being inserted as the ne= w > primary image, or explicitly as the last resort, or somewhere in the > middle). An optional parameter, that defaults to appending, may be ok,= > but we definitely need to consider how the order of children is affecte= d > by hot-add. However, the order should be queriable after the fact, and there are three ways I see to accomplish this: (1) Make this information queriable as driver-specific BDS information. I personally don't like it very much, but it would be fine. (2) Implement query-block-node-tree, make the order of child nodes significant and thus represent the FIFO order there. I don't like this because it would mean returning two orders through that child node list: One is the numeric order (children.0, children.1, ...) and another is the FIFO order, which are not necessarily equal. (3) Fix FIFO order to the child name (its role). I'm very much in favor of this. While I don't have good arguments against (1), I think I have good arguments for (3) instead: It just doesn't make sense to have a numeric order of children if this order doesn't mean anything; especially if you suddenly do need the list of child nodes to be ordered. To me, it doesn't make any sense to introduce a new hidden order which takes precedence over this obvious user-visible order. Max --8rcqTlLcAOPhMm09BRE8BCkw8vNhIr4Ui-- --Rgws7DHOnnFoMTQtlqP4CnB5iH43gssMr 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+qR6AAoJEDuxQgLoOKytKrYIAJe4FvE+rXvxtYbhgU2HK9i+ 1jzWeVr5SbLNrSCVma6MGEg1Afgm7DN8K7gzLqu3rQRTklJAWhrfZCjcEG9i3k++ P/5F8TYciHNhSfxFEavaJQi15S6XGHC/ihX1SkRsboQtESxc5IWTmEWzELgzgrcg Ze/piAgFS2YM+iA90GiVs3ZsRWUHs2+JLCpfgM7hQNwzxcUV/Xab1BJGc+V0zTGO tjkXb2qNb6KlhsNA23SAdgOolhPMW9UR1Eq6U3CN3KxZVUtqdOgIAna9+OGApUIR ZW0tLcmfqwqifEjeDqhqiutoJLGi+/5NBb1VXPhFxgQkhR92ih/6WlbJcfZhJUQ= =ZTAH -----END PGP SIGNATURE----- --Rgws7DHOnnFoMTQtlqP4CnB5iH43gssMr--