qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] scsi: add block job opblockers


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] scsi: add block job opblockers for scsi-block
Date: Thu, 5 Apr 2018 13:59:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 12/03/2018 12:58, Kevin Wolf wrote:
>> - users of dirty bitmaps would call use perm/shared_perm as in your
>> message above
>>
>> - dirty bitmaps creation calls bdrv_get_cumulative_perm (which should
>> now become public) and checks that it doesn't have BLK_PERM_BYPASS in
>> shared_perm
> 
> My proposal was really that users of dirty bitmaps don't change
> anything, but we do everything in the dirty bitmap implementation. Dirty
> bitmap creation would add a BdrvChild with the above permissions.
> Deleting a dirty bitmap would remove the BdrvChild again.

This is also better because it works if somebody requests
BLK_PERM_BYPASS after dirty bitmap creation.

However, is there any better way than also creating a dummy BlockDriver
and BlockDriverState?  I first thought of a root role similar to
BlockBackend's, but BdrvChildRole doesn't have a way to inject its own
permissions.  I then tried moving bdrv_child_perm to BdrvChildRole, and
that almost works except that child_backing has special requirements
(mostly due to commit_top and mirror_top's special block drivers).

Perhaps child_perm should be in BdrvChildRole and BlockDriverState
should only have a bdrv_get_backing_perm (called by
child_backing.child_perm).  This makes sense to me since those
permissions are specific to the driver, e.g. whether it has metadata at
all.  But this becomes 2.13 material.

Do you still object to the two opblocker patches?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]