Re: [Qemu-devel] [PATCH v2 11/16] block/dirty-bitmap: Add bdrv_dirty_iter_next_area

[Max Reitz]

On 2018-02-27 10:06, Fam Zheng wrote:
> On Mon, 01/22 23:08, Max Reitz wrote:
>> This new function allows to look for a consecutively dirty area in a
>> dirty bitmap.
>>
>> Signed-off-by: Max Reitz <address@hidden>
>> ---
>>  include/block/dirty-bitmap.h |  2 ++
>>  block/dirty-bitmap.c         | 51 
>> ++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 53 insertions(+)
>>
>> diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
>> index a591c27213..35f3ccc44c 100644
>> --- a/include/block/dirty-bitmap.h
>> +++ b/include/block/dirty-bitmap.h
>> @@ -79,6 +79,8 @@ void bdrv_set_dirty_bitmap_locked(BdrvDirtyBitmap *bitmap,
>>  void bdrv_reset_dirty_bitmap_locked(BdrvDirtyBitmap *bitmap,
>>                                      int64_t offset, int64_t bytes);
>>  int64_t bdrv_dirty_iter_next(BdrvDirtyBitmapIter *iter);
>> +bool bdrv_dirty_iter_next_area(BdrvDirtyBitmapIter *iter, uint64_t 
>> max_offset,
>> +                               uint64_t *offset, int *bytes);
>>  void bdrv_set_dirty_iter(BdrvDirtyBitmapIter *hbi, int64_t offset);
>>  int64_t bdrv_get_dirty_count(BdrvDirtyBitmap *bitmap);
>>  int64_t bdrv_get_meta_dirty_count(BdrvDirtyBitmap *bitmap);
>> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
>> index 50564fa1e2..484b5dda43 100644
>> --- a/block/dirty-bitmap.c
>> +++ b/block/dirty-bitmap.c
>> @@ -501,6 +501,57 @@ int64_t bdrv_dirty_iter_next(BdrvDirtyBitmapIter *iter)
>>      return hbitmap_iter_next(&iter->hbi, true);
>>  }
>>  
>> +/**
>> + * Return the next consecutively dirty area in the dirty bitmap
>> + * belonging to the given iterator @iter.
>> + *
>> + * @max_offset: Maximum value that may be returned for
>> + *              *offset + *bytes
>> + * @offset:     Will contain the start offset of the next dirty area
>> + * @bytes:      Will contain the length of the next dirty area
>> + *
>> + * Returns: True if a dirty area could be found before max_offset
>> + *          (which means that *offset and *bytes then contain valid
>> + *          values), false otherwise.
> 
> Also document the change to the iter cursor depending on the return value?

Good point, since it may be unexpected that it isn't advanced if
max_offset would be exceeded.

Max

signature.asc
Description: OpenPGP digital signature