On 6/6/19 1:41 PM, John Snow wrote: > Instead of bdrv_can_store_new_bitmap, rework this as > bdrv_add_persistent_dirty_bitmap. This makes a more obvious symmetry > with bdrv_remove_persistent_dirty_bitmap. Most importantly, we are free > to modify the driver state because we know we ARE adding a bitmap > instead of simply being asked if we CAN store one. > > As part of this symmetry, move this function next to > bdrv_remove_persistent_bitmap in block/dirty-bitmap.c. > > To cement this semantic distinction, use a bitmap object instead of the > (name, granularity) pair as this allows us to set persistence as a > condition of the "add" succeeding. > > Notably, the qcow2 implementation still does not actually store the new > bitmap at add time, but merely ensures that it will be able to at store > time. > > Signed-off-by: John Snow <js...@redhat.com> > ---
> +++ b/include/block/dirty-bitmap.h > @@ -38,6 +38,9 @@ int bdrv_dirty_bitmap_check(const BdrvDirtyBitmap *bitmap, > uint32_t flags, > Error **errp); > void bdrv_release_dirty_bitmap(BlockDriverState *bs, BdrvDirtyBitmap > *bitmap); > void bdrv_release_named_dirty_bitmaps(BlockDriverState *bs); > +int bdrv_add_persistent_dirty_bitmap(BlockDriverState *bs, > + BdrvDirtyBitmap *bitmap, > + Error **errp); Indentation looks off. Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
