From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCPkU-0007Z3-Cw for qemu-devel@nongnu.org; Fri, 14 Sep 2012 02:51:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCPkR-0005Pc-18 for qemu-devel@nongnu.org; Fri, 14 Sep 2012 02:51:34 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:45701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCPkQ-0005PY-Qs for qemu-devel@nongnu.org; Fri, 14 Sep 2012 02:51:30 -0400 Received: by wgbdr1 with SMTP id dr1so295537wgb.10 for ; Thu, 13 Sep 2012 23:51:29 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5052D3ED.3000706@redhat.com> Date: Fri, 14 Sep 2012 08:51:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <01df3140216ac0398bfb3a295c553c42cdf31e5b.1347548248.git.jcody@redhat.com> <5052060A.5010304@redhat.com> <50521531.6010308@redhat.com> <50522C73.5030100@redhat.com> <50522E32.4030406@redhat.com> <505237A6.7090202@redhat.com> <50524246.5080800@redhat.com> <5052540F.5050501@redhat.com> In-Reply-To: <5052540F.5050501@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: kwolf@redhat.com, supriyak@linux.vnet.ibm.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com Il 13/09/2012 23:45, Jeff Cody ha scritto: > While there are more changes this way, I think it cleans up the code a > bit. The advantage is that bs->open_flags actually reflects the open > flags that are currently in use. One disadvantage I see is that it > seems a bit odd to have BDRV_O_CACHE_WCE cleared and BDRV_O_CACHE_WB > set, until you think about them being intended for different layers. It's more weird to see BDRV_O_CACHE_WCE set and BDRV_O_CACHE_WB cleared. :) > Maybe that is part of the underlying problem - there is one open_flags > variable in the BDS, that has some flags intended for all layers in the > block stack, and some flags specific to a layer. Yes, that's true. Paolo