Re: [PATCH RFC v2 1/5] block: add bitmap-populate job

[Eric Blake <eblake@redhat.com>]

On 6/16/20 2:46 PM, Eric Blake wrote:

>>> +BlockJob *bitpop_job_create(
> 
>>> +    if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP_SOURCE, errp)) {
>>> +        return NULL;
>>> +    }
>>
>> What does this protect? And why does BACKUP_SOURCE describe acccurately
>> what this job does?
> 
> I'm less certain what the BLOCK_OP_TYPE_* constants are supposed to 
> block, or if this is just copy/paste from backup.c. Does BlockOpType in 
> block.h need a new entry?

As it is, our code base has slowly moved away from op_blockers.  We no 
longer have any explicit bdrv_op_block() except when blocking 
everything, then immediately followed up with unblocking a mere subset 
of all of the defined op types:

block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_COMMIT_TARGET,
block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_STREAM,
block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_SOURCE,
block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_TARGET,
block/replication.c:        bdrv_op_unblock(top_bs, 
BLOCK_OP_TYPE_DATAPLANE, s->blocker);
blockjob.c:    bdrv_op_unblock(bs, BLOCK_OP_TYPE_DATAPLANE, job->blocker);

Are we at the point where we can ditch op_blockers altogether in favor 
of the block permissions system?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org