From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avz7l-00032A-G0 for qemu-devel@nongnu.org; Thu, 28 Apr 2016 23:29:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1avz7k-0005AL-O4 for qemu-devel@nongnu.org; Thu, 28 Apr 2016 23:29:49 -0400 Date: Fri, 29 Apr 2016 11:29:48 +0800 From: Fam Zheng Message-ID: <20160429032948.GH1421@ad.usersys.redhat.com> References: <1461849406-29743-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461849406-29743-1-git-send-email-kwolf@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 00/17] block: Convert .bdrv_read/write to .bdrv_preadv/pwritev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-block@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, sw@weilnetz.de, qemu-devel@nongnu.org On Thu, 04/28 15:16, Kevin Wolf wrote: > This series introduces a new BlockDriver interface, which will hopefully be the > final one, or at least good enough for another few years: .bdrv_preadv/pwritev. > It is based on coroutines, vectored, has flags and uses a byte granularity. > This is now the preferred interface for new drivers. > > All drivers still using the legacy interface .bdrv_read/write are converted to > the new interface and the emulation code we had for the old interface is > removed. Most of the drivers become zero-copy with these patches as they are > vectored now; only vvfat continues to allocate a bounce buffer. > > The less obscure formats (vmdk, vdi, vpc) also natively support byte-aligned > requests now. The block layer is still enforcing a minimal alignment of 512, so > this isn't actually used yet, but in a next step, we can lift this restriction > for drivers that implement .bdrv_preadv/pwritev. Code working on byte granularity is consistent and much nicer to read! Though I'm not 100% sure about the compressed write change in VMDK, but there is apparently nothing wrong, too. So: Reviewed-by: Fam Zheng