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
