From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMjdv-0005r7-Bn for qemu-devel@nongnu.org; Thu, 19 Sep 2013 15:12:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMjdn-0000eE-Hc for qemu-devel@nongnu.org; Thu, 19 Sep 2013 15:11:59 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:58022 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMjdn-0000dx-5z for qemu-devel@nongnu.org; Thu, 19 Sep 2013 15:11:51 -0400 Message-ID: <523B4C69.7040300@kamp.de> Date: Thu, 19 Sep 2013 21:11:37 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1379425736-11326-1-git-send-email-pl@kamp.de> <1379425736-11326-7-git-send-email-pl@kamp.de> <523B481C.50405@redhat.com> In-Reply-To: <523B481C.50405@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2 06/20] block: add discard and write_zeroes limits and alignment to BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, stefanha@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, pbonzini@redhat.com Am 19.09.2013 20:53, schrieb Eric Blake: > On 09/17/2013 07:48 AM, Peter Lieven wrote: >> Signed-off-by: Peter Lieven >> --- >> include/block/block_int.h | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) > Reviewed-by: Eric Blake > >> + >> + /* optimal alignment for write zeroes requests in sectors */ >> + int64_t write_zeroes_alignment; >> + Paolo voted for a BlockLimits struct to be nested into the BlockDriverState. It would make it easier if the settings have to be copied (like in raw_open). There might be more limits in the future so it might be good that its not necessary to change the code everywhere. >> /* do we need to tell the quest if we have a volatile write cache? */ >> int enable_write_cache; > Hmm, I just pointed out to Paolo that this ought to be bool. But as it > is in the context and not your actual patch, it has no bearing on this > series, and even if that gets changed first, git's pretty good about > context-only conflict resolution. > If I put a v3 which is likely I can put a patch for that in as well. Peter