Re: [Qemu-devel] [PATCH 0/3] Add 'blockdev-del' command

[Markus Armbruster]

Alberto Garcia <address@hidden> writes:

> Here's my first attempt at the 'blockdev-del' command.
>
> This series goes on top of Max's "BlockBackend and media" v6:
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02810.html
>
> With Max's code, 'blockdev-add' can now create a BlockDriverState with
> or without a BlockBackend (depending on whether the 'id' parameter is
> passed).
>
> Therefore, 'blockdev-del' can be used to delete a backend and/or a
> BDS.
>
> The way it works is simple: it receives a single 'device' parameter
> which can refer to a block backend or a node name.
>
>  - If it's a block backend, it will delete it along with its attached
>    BDS (if any).
>
>  - If it's a node name, it will delete the BDS along with the backend
>    it is attached to (if any).
>
>  - If you're wondering whether it's possible to delete the BDS but not
>    the backend it is attached to, there is already eject or
>    blockdev-remove-medium for that.
>
> If either the backend or the BDS are being used (refcount > 1, or if
> the BDS has any parents) the command fails.
>
> The series includes bunch of test cases with different scenarios
> (nodes with and without backend, empty backend, backing images, block
> jobs, Quorum).

I almost certainly won't have the time to review this series, but I can
still indulge in a little drive-by shooting :)

blockdev-add is a big & hairy feature that has taken considerable time
to develop, spanning multiple releases, and still isn't quite done
(never been closer, though).  As such, it's a textbook example of an
experimental interface, and should have been x-blockdev-add.  We messed
that up, and it's probably not worth renaming now.

Quite a few users have been trying to use blockdev-add, and ran into
roadblocks sooner or later.  Inevitable, given its incomplete state.
Perhaps an x- prefix providing fair warning would've saved them trouble,
but that's water under the bridge now.  We tried to warn them off with
scary documentation instead (commit da2cf4e).

Naturally, running into an obvious roadblock early is less bad than
running into a subtle one late.  The lack of blockdev-del has served as
an obvious early one.

Mind, that's not an objection to implementing it now.  I think the
time's ripe, actually.  I just want us to try to erect a proper warning
sign where the "no blockdev-del" roadblock used to be.  Naming it
x-blockdev-del together with a note explaining why it's experimental
should do the trick.