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
On 11/23/2015 09:28 PM, 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
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
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
On 11/20/2015 04:59 AM, Fam Zheng wrote:
> HBitmap is an implementation detail of block dirty bitmap that should be
> hidden
> from users. Introduce a BdrvDirtyBitmapIter to encapsulate the underlying
> HBitmapIter.
>
> A small difference in the interface is, before, an HBitmapIter is
