Re: [RFC PATCH v2 3/4] block: Support multiple reopening with x-blockdev-reopen

[Kevin Wolf <kwolf@redhat.com>]

Am 09.02.2021 um 09:03 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 08.02.2021 21:44, Alberto Garcia wrote:
> > Signed-off-by: Alberto Garcia <berto@igalia.com>
> > ---
> >   qapi/block-core.json       |  2 +-
> >   include/block/block.h      |  1 +
> >   block.c                    | 16 +++++--
> >   blockdev.c                 | 85 +++++++++++++++++++++-----------------
> >   tests/qemu-iotests/155     |  9 ++--
> >   tests/qemu-iotests/165     |  4 +-
> >   tests/qemu-iotests/245     | 27 +++++++-----
> >   tests/qemu-iotests/248     |  2 +-
> >   tests/qemu-iotests/248.out |  2 +-
> >   tests/qemu-iotests/298     |  4 +-
> >   10 files changed, 89 insertions(+), 63 deletions(-)
> > 
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index c0e7c23331..b9fcf20a81 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -4177,7 +4177,7 @@
> >   # Since: 4.0
> >   ##
> >   { 'command': 'x-blockdev-reopen',
> > -  'data': 'BlockdevOptions', 'boxed': true }
> > +  'data': { 'options': ['BlockdevOptions'] } }
> 
> Do we also want to drop x- prefix?

libvirt really wants to have a stable blockdev-reopen interface in 6.0
because enabling the incremental backup code depends on this (they just
toggle the readonly flag if I understand correctly, so most of the work
we're currently doing isn't even relevant at this moment for libvirt).

Given that the soft freeze is coming closer (March 16), I wonder if we
should just make this API change and declare the interface stable. We
can then make Vladimir's fixes and the file reopening on top of it - if
it's in time for 6.0, that would be good, but if not we could move it to
6.1 without impacting libvirt.

I think we're reasonable confident that the QAPI interfaces are right,
even if maybe not that all aspects of the implementation are right yet.

What do you think?

Kevin