From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a19eB-0002ix-R5 for qemu-devel@nongnu.org; Tue, 24 Nov 2015 04:12:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a19e6-0003Xj-RB for qemu-devel@nongnu.org; Tue, 24 Nov 2015 04:12:23 -0500 Message-ID: <565429E4.1090903@virtuozzo.com> Date: Tue, 24 Nov 2015 12:12:04 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1448013593-14282-1-git-send-email-famz@redhat.com> <1448013593-14282-3-git-send-email-famz@redhat.com> <5653866A.2080003@redhat.com> <20151124022814.GA26733@ad.usersys.redhat.com> In-Reply-To: <20151124022814.GA26733@ad.usersys.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for 2.6 2/3] block: Hide HBitmap in block dirty bitmap interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , John Snow Cc: Kevin Wolf , qemu-block@nongnu.org, Jeff Cody , qemu-devel@nongnu.org, mreitz@redhat.com, pbonzini@redhat.com On 24.11.2015 05:28, Fam Zheng wrote: > On Mon, 11/23 16:34, John Snow wrote: >> Hmm, what's the idea, here? >> >> This patch does a lot more than just hide hbitmap details from callers >> of block_dirty_bitmap functions. >> >> So we're changing the backing hbitmap to always be one where g=0 and the >> number of physical bits directly is (now) the same as the number of >> 'virtual' bits, pre-patch. Then, to compensate, we handle the shift math >> to convert the bitmap granularity to sector size and vice-versa in the >> Block Dirty Bitmap layer instead of in the hbitmap layer. >> >> What's the benefit? It looks like we just pull all the implementation >> details up from hbitmap and into BdrvDirtyBitmap, which I am not >> immediately convinced of as being a benefit. > It feels counter intuitive to me with hbitmap handling granularity, it makes it > more like a HGranularityBitmap rather than HBitmap, and is unnecessarily > complex to work on. > > Now it's simplified in that only one BdrvDirtyBitmap needs to care about the > granularity, and which I think is a big benefit when we are going to extend the > dirty bitmap interface, for example to serialize and deserialize for > persistence. > > Fam But what is the relation from this to adding iterator interface? This seems like this patch do two different things: 1) granularity changes, described in quotation above 2) adding iterator related things, described in commit message -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.