On 09/10/2015 07:39 AM, Alberto Garcia wrote: > If set to true, the image will be opened with the BDRV_O_NO_BACKING > flag. This is useful for creating snapshots using images opened with > blockdev-add, since they are not supposed to have a backing image > before the operation. > > Signed-off-by: Alberto Garcia <[email protected]> > --- > block.c | 5 +++++ > qapi/block-core.json | 6 +++++- > 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/block.c b/block.c
> index 22d3b0e..4be32fb 100644
> --- a/block.c
> +++ b/block.c
> @@ -1469,6 +1469,11 @@ static int bdrv_open_inherit(BlockDriverState **pbs,
> const char *filename,
>
> assert(drvname || !(flags & BDRV_O_PROTOCOL));
>
> + if (qdict_get_try_bool(options, "ignore-backing", false)) {
> + flags |= BDRV_O_NO_BACKING;
> + }
> + qdict_del(options, "ignore-backing");
What happens if the user specified "ignore-backing":true, "backing":...?
Should that be a hard error?
> { 'struct': 'BlockdevOptionsGenericCOWFormat',
> 'base': 'BlockdevOptionsGenericFormat',
> - 'data': { '*backing': 'BlockdevRef' } }
> + 'data': { '*backing': 'BlockdevRef',
> + '*ignore-backing': 'bool' } }
Depending on whether the answer to my question is that we already behave
sanely and don't leave a BlockdevRef dangling if the caller mixes the
two approaches, then:
Reviewed-by: Eric Blake <[email protected]>
But design-wise, would it make sense to support:
"backing":null
as an explicit request to not open a backing file? Right now, qapi does
not have a way to express 'null' as part of an alternate type; but if it
did, BlockdevRef would merely add 'null' as one of its allowed
alternates. Then we wouldn't need ignore-backing from the QMP
perspective. But I'm still not sure how it would map to the command line
perspective.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
