Re: [Qemu-devel] [PATCH for 2.6 2/3] block: Hide HBitmap in block dirty bitmap interface

[Fam Zheng]

On Tue, 11/24 12:12, Vladimir Sementsov-Ogievskiy wrote:
> 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
> 

OK, let's try to split this so we still have the BdrvDirtyBitmapIter change
even if the granularity movement is rejected.

Fam