Hi!

The main feature here is improvement of _next_dirty_area API, which I'm
going to use then for backup / block-copy.

v2:
01: just use INT64_MAX instead of adding new constant
08: add separate function nbd_extent_array_convert_to_be and converted
    state of NBDExtentArray, to make these things explicit, and avoid
    extra memdup.
09: Save part of comment for bitmap_to_extents(), add Eric's r-b

Vladimir Sementsov-Ogievskiy (10):
  hbitmap: assert that we don't create bitmap larger than INT64_MAX
  hbitmap: move hbitmap_iter_next_word to hbitmap.c
  hbitmap: unpublish hbitmap_iter_skip_words
  hbitmap: drop meta bitmaps as they are unused
  block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
  block/dirty-bitmap: add _next_dirty API
  block/dirty-bitmap: improve _next_dirty_area API
  nbd/server: introduce NBDExtentArray
  nbd/server: use bdrv_dirty_bitmap_next_dirty_area
  block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty

 include/block/dirty-bitmap.h |   9 +-
 include/qemu/hbitmap.h       |  97 +++--------
 block/dirty-bitmap.c         |  16 +-
 block/mirror.c               |  15 +-
 block/qcow2-bitmap.c         |  11 +-
 nbd/server.c                 | 242 +++++++++++++--------------
 tests/test-hbitmap.c         | 314 +++++++++++++----------------------
 util/hbitmap.c               | 133 +++++++++------
 8 files changed, 373 insertions(+), 464 deletions(-)

-- 
2.21.0

On 10/22/19 7:58 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
> 
> The main feature here is improvement of _next_dirty_area API, which I'm
> going to use then for backup / block-copy.
> 
> v2:
> 01: just use INT64_MAX instead of adding new constant
> 08: add separate function nbd_extent_array_convert_to_be and converted
>      state of NBDExtentArray, to make these things explicit, and avoid
>      extra memdup.
> 09: Save part of comment for bitmap_to_extents(), add Eric's r-b

Is any of this series a bug fix important to get into -rc2?  Or is it 
safe to defer to the 5.0 timeframe?

> 
> Vladimir Sementsov-Ogievskiy (10):
>    hbitmap: assert that we don't create bitmap larger than INT64_MAX
>    hbitmap: move hbitmap_iter_next_word to hbitmap.c
>    hbitmap: unpublish hbitmap_iter_skip_words
>    hbitmap: drop meta bitmaps as they are unused
>    block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
>    block/dirty-bitmap: add _next_dirty API
>    block/dirty-bitmap: improve _next_dirty_area API
>    nbd/server: introduce NBDExtentArray
>    nbd/server: use bdrv_dirty_bitmap_next_dirty_area
>    block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

14.11.2019 21:47, Eric Blake wrote:
> On 10/22/19 7:58 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi!
>>
>> The main feature here is improvement of _next_dirty_area API, which I'm
>> going to use then for backup / block-copy.
>>
>> v2:
>> 01: just use INT64_MAX instead of adding new constant
>> 08: add separate function nbd_extent_array_convert_to_be and converted
>>      state of NBDExtentArray, to make these things explicit, and avoid
>>      extra memdup.
>> 09: Save part of comment for bitmap_to_extents(), add Eric's r-b
> 
> Is any of this series a bug fix important to get into -rc2?

Nothing

> Or is it safe to defer to the 5.0 timeframe?

Yes, no doubts.

> 
>>
>> Vladimir Sementsov-Ogievskiy (10):
>>    hbitmap: assert that we don't create bitmap larger than INT64_MAX
>>    hbitmap: move hbitmap_iter_next_word to hbitmap.c
>>    hbitmap: unpublish hbitmap_iter_skip_words
>>    hbitmap: drop meta bitmaps as they are unused
>>    block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
>>    block/dirty-bitmap: add _next_dirty API
>>    block/dirty-bitmap: improve _next_dirty_area API
>>    nbd/server: introduce NBDExtentArray
>>    nbd/server: use bdrv_dirty_bitmap_next_dirty_area
>>    block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty
>>
> 


-- 
Best regards,
Vladimir