On 12/02/2018 15:50, Paolo Bonzini wrote: > On 12/02/2018 15:48, Kevin Wolf wrote: >> Am 12.02.2018 um 15:32 hat Paolo Bonzini geschrieben: >>> Okay, we are in agreement about this and you expressed very well why I >>> (at the gut feeling level) didn't like the old op blockers. But you >>> bypassed the real question, which is: should I send a pull request for >>> these two patches or not? :) >> I didn't spell it out that explicitly, but this is essentially a NACK. >> I'd very much prefer if you could replace it with the proper solution. >> Of course, we can always make exceptions when there is a good reason, >> but with 2.12 still two months away, I doubt we have one. > Ok, I don't mind explicitness. I'll keep these two patches in the queue > for now.
It's now one month away. Regarding the solution below: > I propose a new BLK_PERM_BYPASS that allows its users to bypass the > block layer I/O functions. In other words, bdrv_aio_ioctl() would > require that you got this permission. A dirty bitmap would keep a > BdrvChild with perm=0, shared=BLK_PERM_ALL & ~BLK_PERM_BYPASS, so you > can never have a dirty bitmap and a device using ioctls attached to the > BDS at the same time. I suppose it would be like: - scsi-block/scsi-generic call blk_set_perm with perm == shared == BLK_PERM_BYPASS - 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 Anything I'm missing? Paolo
