Am 01.10.2018 um 12:29 hat Vladimir Sementsov-Ogievskiy geschrieben: > Add some functions to use fleecing-hook internally from backup job in > further commit. > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> > --- > include/block/block.h | 9 ++++++++ > block/fleecing-hook.c | 51 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+) > > diff --git a/include/block/block.h b/include/block/block.h > index 4edc1e8afa..018751b6ea 100644 > --- a/include/block/block.h > +++ b/include/block/block.h > @@ -710,4 +710,13 @@ int coroutine_fn bdrv_co_copy_range(BdrvChild *src, > uint64_t src_offset, > BdrvChild *dst, uint64_t dst_offset, > uint64_t bytes, BdrvRequestFlags > read_flags, > BdrvRequestFlags write_flags); > + > + > +BlockDriverState *bdrv_fleecing_hook_append(BlockDriverState *source, > + BlockDriverState *target, > + const char *copy_bitmap_name, > + Error **errp); > +void bdrv_fleecing_hook_drop(BlockDriverState *hook); > +uint64_t bdrv_fleecing_hook_progress(BlockDriverState *hook);
Public block.h interfaces that are specific to a single driver are bad design. If at all possible, the generic block layer shouldn't know anything about specific drivers. Luckily, if you make the driver more consistent with what mirror and commit are doing, you won't need public interfaces any more and the functions will just become part of the backup job driver. (The backup driver can still be split into multiple source files if necessary, and then use a separate internal header; I'm not sure if this is the case here, though.) Kevin
