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
