[v7,02/10] block: Introduce op_blockers to BlockDriverState

BlockDriverState.op_blockers is an array of lists with BLOCK_OP_TYPE_MAX
elements. Each list is a list of blockers of an operation type
(BlockOpType), that marks this BDS as currently blocked for a certain
type of operation with reason errors stored in the list. The rule of
usage is:

 * BDS user who wants to take an operation should check if there's any
   blocker of the type with bdrv_op_is_blocked().

 * BDS user who wants to block certain types of operation, should call
   bdrv_op_block (or bdrv_op_block_all to block all types of operations,
   which is similar to bdrv_set_in_use of now).

 * A blocker is only referenced by op_blockers, so the lifecycle is
   managed by caller, and shouldn't be lost until unblock, so typically
   a caller does these:

   - Allocate a blocker with error_setg or similar, call bdrv_op_block()
     to block some operations.
   - Hold the blocker, do his job.
   - Unblock operations that it blocked, with the same reason pointer
     passed to bdrv_op_unblock().
   - Release the blocker with error_free().

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block.c                   | 57 +++++++++++++++++++++++++++++++++++++++++++++++
 include/block/block.h     |  6 +++++
 include/block/block_int.h |  5 +++++
 3 files changed, 68 insertions(+)

Fam Zheng <famz@redhat.com> writes:

> BlockDriverState.op_blockers is an array of lists with BLOCK_OP_TYPE_MAX
> elements. Each list is a list of blockers of an operation type
> (BlockOpType), that marks this BDS as currently blocked for a certain
> type of operation with reason errors stored in the list. The rule of
> usage is:
>
>  * BDS user who wants to take an operation should check if there's any
>    blocker of the type with bdrv_op_is_blocked().
>
>  * BDS user who wants to block certain types of operation, should call
>    bdrv_op_block (or bdrv_op_block_all to block all types of operations,
>    which is similar to bdrv_set_in_use of now).


Suggest "is similar to the existing bdrv_set_in_use()"

>
>  * A blocker is only referenced by op_blockers, so the lifecycle is
>    managed by caller, and shouldn't be lost until unblock, so typically
>    a caller does these:
>
>    - Allocate a blocker with error_setg or similar, call bdrv_op_block()
>      to block some operations.
>    - Hold the blocker, do his job.
>    - Unblock operations that it blocked, with the same reason pointer
>      passed to bdrv_op_unblock().
>    - Release the blocker with error_free().
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
>  block.c                   | 57 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/block/block.h     |  6 +++++
>  include/block/block_int.h |  5 +++++
>  3 files changed, 68 insertions(+)
>
> diff --git a/block.c b/block.c
> index 13f001a..c1a3576 100644
> --- a/block.c
> +++ b/block.c
> @@ -4629,6 +4629,63 @@ void bdrv_unref(BlockDriverState *bs)
>      }
>  }
>  
> +struct BdrvOpBlocker {
> +    Error *reason;
> +    QLIST_ENTRY(BdrvOpBlocker) list;
> +};
> +
> +bool bdrv_op_is_blocked(BlockDriverState *bs, BlockOpType op, Error **errp)
> +{
> +    BdrvOpBlocker *blocker;
> +    assert((int) op >= 0 && op < BLOCK_OP_TYPE_MAX);
> +    if (!QLIST_EMPTY(&bs->op_blockers[op])) {
> +        blocker = QLIST_FIRST(&bs->op_blockers[op]);
> +        if (errp) {
> +            *errp = error_copy(blocker->reason);
> +        }
> +        return true;
> +    }
> +    return false;
> +}

Your interface permits registering multiple blockers, but when you're
blocked, you can only find a single blocker (the most recent one, but
that's implementation detail).

If a need for finding all of them should arise, we'll do it.  No change
necessary now.

[...]