[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [RFC PATCH v2 3/4] block: Support multiple reopening with x-blockdev-reopen
Date: Thu, 25 Feb 2021 20:02:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

24.02.2021 15:33, Kevin Wolf wrote:
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).

Do you know what is the case exactly? If they do it to remove dirty bitmap
from backing image after snapshot operation, probably we'd better improve
block-dirty-bitmap-remove command to be able to reopen r-o image?

(I just recently faced such a task)

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?

I think it's OK.. We have it since 4.0. What will we win keeping -x for years? 
Even latest change from updating one device to several could be easily done 
with help of 'alternate' if the command was already stable.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]