diff options
| author | Stefan Hajnoczi <stefanha@redhat.com> | 2025-02-03 13:25:29 -0500 |
|---|---|---|
| committer | Kevin Wolf <kwolf@redhat.com> | 2025-02-06 14:51:10 +0100 |
| commit | fc4e394b2887e15d5f83994e4fc7b26c895c627a (patch) | |
| tree | 823c8cfda83ff5dad6079b938ecf65161dfdaa65 /rust/qemu-api-macros/src | |
| parent | bbf105ef3cc48fff282789e9bf56b7a81e1407bd (diff) | |
| download | qemu-fc4e394b2887e15d5f83994e4fc7b26c895c627a.zip qemu-fc4e394b2887e15d5f83994e4fc7b26c895c627a.tar.gz qemu-fc4e394b2887e15d5f83994e4fc7b26c895c627a.tar.bz2 | |
block: remove unused BLOCK_OP_TYPE_DATAPLANE
BLOCK_OP_TYPE_DATAPLANE prevents BlockDriverState from being used by
virtio-blk/virtio-scsi with IOThread. Commit b112a65c52aa ("block:
declare blockjobs and dataplane friends!") eliminated the main reason
for this blocker in 2014.
Nowadays the block layer supports I/O from multiple AioContexts, so
there is even less reason to block IOThread users. Any legitimate
reasons related to interference would probably also apply to
non-IOThread users.
The only remaining users are bdrv_op_unblock(BLOCK_OP_TYPE_DATAPLANE)
calls after bdrv_op_block_all(). If we remove BLOCK_OP_TYPE_DATAPLANE
their behavior doesn't change.
Existing bdrv_op_block_all() callers that don't explicitly unblock
BLOCK_OP_TYPE_DATAPLANE seem to do so simply because no one bothered to
rather than because it is necessary to keep BLOCK_OP_TYPE_DATAPLANE
blocked.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250203182529.269066-1-stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'rust/qemu-api-macros/src')
0 files changed, 0 insertions, 0 deletions