Re: [Qemu-devel] [PATCH v17 02/14] block: Introduce op_blockers to BlockDriverState

[Fam Zheng]

On Sun, 04/06 19:49, Jeff Cody wrote:
> On Mon, Mar 10, 2014 at 03:25:58PM +0800, Fam Zheng wrote:
> > 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 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().
> 
> Is there a reason to assume there will be atypical usages that don't
> follow these steps?  If not, could the Error reason resource be
> allocated inside the block() operation if non-NULL, and freed inside
> the unblock() operations?

Could work as well. It's just that the current interface is following the style
of migration blocker.

Thanks,
Fam