Tree:
bc54fb0168
10.1-testing
99888-virtio-zero-init-c9s
block
coverity
master
stable-0.10
stable-0.11
stable-0.12
stable-0.13
stable-0.14
stable-0.15
stable-1.0
stable-1.1
stable-1.2
stable-1.3
stable-1.4
stable-1.5
stable-1.6
stable-1.7
stable-10.0
stable-10.1
stable-10.2
stable-2.0
stable-2.1
stable-2.10
stable-2.11
stable-2.12
stable-2.2
stable-2.3
stable-2.4
stable-2.5
stable-2.6
stable-2.7
stable-2.8
stable-2.9
stable-3.0
stable-3.1
stable-4.0
stable-4.1
stable-4.2
stable-5.0
stable-6.0
stable-6.0-staging
stable-6.1
stable-7.2
stable-7.2-staging
stable-8.0
stable-8.0-staging
stable-8.1
stable-8.2
stable-9.0
stable-9.1
stable-9.2
staging
staging-0.0
staging-10.0
staging-10.1
staging-10.2
staging-7.2
staging-8.0
staging-8.1
staging-8.2
staging-9.0
staging-9.1
staging-9.2
staging-mjt-test
stsquad-hotfix
tracing
initial
release_0_10_0
release_0_10_1
release_0_10_2
release_0_5_1
release_0_6_0
release_0_6_1
release_0_7_0
release_0_7_1
release_0_8_1
release_0_8_2
release_0_9_0
release_0_9_1
staging-mjt-test
trivial-patches-pull-request
v0.1.0
v0.1.1
v0.1.3
v0.1.4
v0.1.5
v0.1.6
v0.10.0
v0.10.1
v0.10.2
v0.10.3
v0.10.4
v0.10.5
v0.10.6
v0.11.0
v0.11.0-rc0
v0.11.0-rc1
v0.11.0-rc2
v0.11.1
v0.12.0
v0.12.0-rc0
v0.12.0-rc1
v0.12.0-rc2
v0.12.1
v0.12.2
v0.12.3
v0.12.4
v0.12.5
v0.13.0
v0.13.0-rc0
v0.13.0-rc1
v0.13.0-rc2
v0.13.0-rc3
v0.14.0
v0.14.0-rc0
v0.14.0-rc1
v0.14.0-rc2
v0.14.1
v0.15.0
v0.15.0-rc0
v0.15.0-rc1
v0.15.0-rc2
v0.15.1
v0.2.0
v0.3.0
v0.4.0
v0.4.1
v0.4.2
v0.4.3
v0.4.4
v0.5.0
v0.5.1
v0.6.0
v0.6.1
v0.7.0
v0.7.1
v0.8.1
v0.8.2
v0.9.0
v0.9.1
v1.0
v1.0-rc0
v1.0-rc1
v1.0-rc2
v1.0-rc3
v1.0-rc4
v1.0.1
v1.1-rc0
v1.1-rc1
v1.1-rc2
v1.1.0
v1.1.0-rc2
v1.1.0-rc3
v1.1.0-rc4
v1.1.1
v1.1.2
v1.2.0
v1.2.0-rc0
v1.2.0-rc1
v1.2.0-rc2
v1.2.0-rc3
v1.2.1
v1.2.2
v1.3.0
v1.3.0-rc0
v1.3.0-rc1
v1.3.0-rc2
v1.3.1
v1.4.0
v1.4.0-rc0
v1.4.0-rc1
v1.4.0-rc2
v1.4.1
v1.4.2
v1.5.0
v1.5.0-rc0
v1.5.0-rc1
v1.5.0-rc2
v1.5.0-rc3
v1.5.1
v1.5.2
v1.5.3
v1.6.0
v1.6.0-rc0
v1.6.0-rc1
v1.6.0-rc2
v1.6.0-rc3
v1.6.1
v1.6.2
v1.7.0
v1.7.0-rc0
v1.7.0-rc1
v1.7.0-rc2
v1.7.1
v1.7.2
v10.0.0
v10.0.0-rc0
v10.0.0-rc1
v10.0.0-rc2
v10.0.0-rc3
v10.0.0-rc4
v10.0.1
v10.0.2
v10.0.3
v10.0.4
v10.0.5
v10.0.6
v10.0.7
v10.0.8
v10.1.0
v10.1.0-rc0
v10.1.0-rc1
v10.1.0-rc2
v10.1.0-rc3
v10.1.0-rc4
v10.1.1
v10.1.2
v10.1.3
v10.1.4
v10.2.0
v10.2.0-rc1
v10.2.0-rc2
v10.2.0-rc3
v10.2.0-rc4
v10.2.1
v2.0.0
v2.0.0-rc0
v2.0.0-rc1
v2.0.0-rc2
v2.0.0-rc3
v2.0.1
v2.0.2
v2.1.0
v2.1.0-rc0
v2.1.0-rc1
v2.1.0-rc2
v2.1.0-rc3
v2.1.0-rc4
v2.1.0-rc5
v2.1.1
v2.1.2
v2.1.3
v2.10.0
v2.10.0-rc0
v2.10.0-rc1
v2.10.0-rc2
v2.10.0-rc3
v2.10.0-rc4
v2.10.1
v2.10.2
v2.11.0
v2.11.0-rc0
v2.11.0-rc1
v2.11.0-rc2
v2.11.0-rc3
v2.11.0-rc4
v2.11.0-rc5
v2.11.1
v2.11.2
v2.12.0
v2.12.0-rc0
v2.12.0-rc1
v2.12.0-rc2
v2.12.0-rc3
v2.12.0-rc4
v2.12.1
v2.2.0
v2.2.0-rc0
v2.2.0-rc1
v2.2.0-rc2
v2.2.0-rc3
v2.2.0-rc4
v2.2.0-rc5
v2.2.1
v2.3.0
v2.3.0-rc0
v2.3.0-rc1
v2.3.0-rc2
v2.3.0-rc3
v2.3.0-rc4
v2.3.1
v2.4.0
v2.4.0-rc0
v2.4.0-rc1
v2.4.0-rc2
v2.4.0-rc3
v2.4.0-rc4
v2.4.0.1
v2.4.1
v2.5.0
v2.5.0-rc0
v2.5.0-rc1
v2.5.0-rc2
v2.5.0-rc3
v2.5.0-rc4
v2.5.1
v2.5.1.1
v2.6.0
v2.6.0-rc0
v2.6.0-rc1
v2.6.0-rc2
v2.6.0-rc3
v2.6.0-rc4
v2.6.0-rc5
v2.6.1
v2.6.2
v2.7.0
v2.7.0-rc0
v2.7.0-rc1
v2.7.0-rc2
v2.7.0-rc3
v2.7.0-rc4
v2.7.0-rc5
v2.7.1
v2.8.0
v2.8.0-rc0
v2.8.0-rc1
v2.8.0-rc2
v2.8.0-rc3
v2.8.0-rc4
v2.8.1
v2.8.1.1
v2.9.0
v2.9.0-rc0
v2.9.0-rc1
v2.9.0-rc2
v2.9.0-rc3
v2.9.0-rc4
v2.9.0-rc5
v2.9.1
v3.0.0
v3.0.0-rc0
v3.0.0-rc1
v3.0.0-rc2
v3.0.0-rc3
v3.0.0-rc4
v3.0.1
v3.1.0
v3.1.0-rc0
v3.1.0-rc1
v3.1.0-rc2
v3.1.0-rc3
v3.1.0-rc4
v3.1.0-rc5
v3.1.1
v3.1.1.1
v4.0.0
v4.0.0-rc0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.0.0-rc4
v4.0.1
v4.1.0
v4.1.0-rc0
v4.1.0-rc1
v4.1.0-rc2
v4.1.0-rc3
v4.1.0-rc4
v4.1.0-rc5
v4.1.1
v4.2.0
v4.2.0-rc0
v4.2.0-rc1
v4.2.0-rc2
v4.2.0-rc3
v4.2.0-rc4
v4.2.0-rc5
v4.2.1
v5.0.0
v5.0.0-rc0
v5.0.0-rc1
v5.0.0-rc2
v5.0.0-rc3
v5.0.0-rc4
v5.0.1
v5.1.0
v5.1.0-rc0
v5.1.0-rc1
v5.1.0-rc2
v5.1.0-rc3
v5.2.0
v5.2.0-rc0
v5.2.0-rc1
v5.2.0-rc2
v5.2.0-rc3
v5.2.0-rc4
v6.0.0
v6.0.0-rc0
v6.0.0-rc1
v6.0.0-rc2
v6.0.0-rc3
v6.0.0-rc4
v6.0.0-rc5
v6.0.1
v6.1.0
v6.1.0-rc0
v6.1.0-rc1
v6.1.0-rc2
v6.1.0-rc3
v6.1.0-rc4
v6.1.1
v6.2.0
v6.2.0-rc0
v6.2.0-rc1
v6.2.0-rc2
v6.2.0-rc3
v6.2.0-rc4
v7.0.0
v7.0.0-rc0
v7.0.0-rc1
v7.0.0-rc2
v7.0.0-rc3
v7.0.0-rc4
v7.1.0
v7.1.0-rc0
v7.1.0-rc1
v7.1.0-rc2
v7.1.0-rc3
v7.1.0-rc4
v7.2.0
v7.2.0-rc0
v7.2.0-rc1
v7.2.0-rc2
v7.2.0-rc3
v7.2.0-rc4
v7.2.1
v7.2.10
v7.2.11
v7.2.12
v7.2.13
v7.2.14
v7.2.15
v7.2.16
v7.2.17
v7.2.18
v7.2.19
v7.2.2
v7.2.20
v7.2.21
v7.2.22
v7.2.3
v7.2.4
v7.2.5
v7.2.6
v7.2.7
v7.2.8
v7.2.9
v8.0.0
v8.0.0-rc0
v8.0.0-rc1
v8.0.0-rc2
v8.0.0-rc3
v8.0.0-rc4
v8.0.1
v8.0.2
v8.0.3
v8.0.4
v8.0.5
v8.1.0
v8.1.0-rc0
v8.1.0-rc1
v8.1.0-rc2
v8.1.0-rc3
v8.1.0-rc4
v8.1.1
v8.1.2
v8.1.3
v8.1.4
v8.1.5
v8.2.0
v8.2.0-rc0
v8.2.0-rc1
v8.2.0-rc2
v8.2.0-rc3
v8.2.0-rc4
v8.2.1
v8.2.10
v8.2.2
v8.2.3
v8.2.4
v8.2.5
v8.2.6
v8.2.7
v8.2.8
v8.2.9
v9.0.0
v9.0.0-rc0
v9.0.0-rc1
v9.0.0-rc2
v9.0.0-rc3
v9.0.0-rc4
v9.0.1
v9.0.2
v9.0.3
v9.0.4
v9.1.0
v9.1.0-rc0
v9.1.0-rc1
v9.1.0-rc2
v9.1.0-rc3
v9.1.0-rc4
v9.1.1
v9.1.2
v9.1.3
v9.2.0
v9.2.0-rc0
v9.2.0-rc1
v9.2.0-rc2
v9.2.0-rc3
v9.2.1
v9.2.2
v9.2.3
v9.2.4
${ noResults }
19 Commits (bc54fb0168961fc61f8752ecdf979e4ab4e2439d)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
c12887e1b0 |
block-coroutine-wrapper: use qemu_get_current_aio_context()
Use qemu_get_current_aio_context() in mixed wrappers and coroutine wrappers so that code runs in the caller's AioContext instead of moving to the BlockDriverState's AioContext. This change is necessary for the multi-queue block layer where any thread can call into the block layer. Most wrappers are IO_CODE where it's safe to use the current AioContext nowadays. BlockDrivers and the core block layer use their own locks and no longer depend on the AioContext lock for thread-safety. The bdrv_create() wrapper invokes GLOBAL_STATE code. Using the current AioContext is safe because this code is only called with the BQL held from the main loop thread. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230912231037.826804-6-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> |
3 years ago |
|
|
b49f4755c7 |
block: remove AioContext locking
This is the big patch that removes aio_context_acquire()/aio_context_release() from the block layer and affected block layer users. There isn't a clean way to split this patch and the reviewers are likely the same group of people, so I decided to do it in one patch. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-ID: <20231205182011.1976568-7-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
2 years ago |
|
|
6bc30f1949 |
graph-lock: remove AioContext locking
Stop acquiring/releasing the AioContext lock in bdrv_graph_wrlock()/bdrv_graph_unlock() since the lock no longer has any effect. The distinction between bdrv_graph_wrunlock() and bdrv_graph_wrunlock_ctx() becomes meaningless and they can be collapsed into one function. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231205182011.1976568-6-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
2 years ago |
|
|
6bc0bcc89f |
block: Fix deadlocks in bdrv_graph_wrunlock()
bdrv_graph_wrunlock() calls aio_poll(), which may run callbacks that have a nested event loop. Nested event loops can depend on other iothreads making progress, so in order to allow them to make progress it must not hold the AioContext lock of another thread while calling aio_poll(). This introduces a @bs parameter to bdrv_graph_wrunlock() whose AioContext is temporarily dropped (which matches bdrv_graph_wrlock()), and a bdrv_graph_wrunlock_ctx() that can be used if the BlockDriverState doesn't necessarily exist any more when unlocking. This also requires a change to bdrv_schedule_unref(), which was relying on the incorrectly taken lock. It needs to take the lock itself now. While this is a separate bug, it can't be fixed a separate patch because otherwise the intermediate state would either deadlock or try to release a lock that we don't even hold. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231115172012.112727-3-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> [kwolf: Fixed up bdrv_schedule_unref()] Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
2 years ago |
|
|
e84c07bc73 |
block-coroutine-wrapper: Add no_co_wrapper_bdrv_rdlock functions
Add a new wrapper type for GRAPH_RDLOCK functions that should be called from coroutine context. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20230929145157.45443-3-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
d21843491a |
block-coroutine-wrapper: Allow arbitrary parameter names
Don't assume specific parameter names like 'bs' or 'blk' in the generated code, but use the actual name. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230911094620.45040-8-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
de90329889 |
block-coroutine-wrapper: Add no_co_wrapper_bdrv_wrlock functions
Add a new wrapper type for GRAPH_WRLOCK functions that should be called from coroutine context. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230911094620.45040-7-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
dea97c1fbd |
block-coroutine-wrapper: Take AioContext lock in no_co_wrappers
All of the functions that currently take a BlockDriverState, BdrvChild or BlockBackend as their first parameter expect the associated AioContext to be locked when they are called. In the case of no_co_wrappers, they are called from bottom halves directly in the main loop, so no other caller can be expected to take the lock for them. This can result in assertion failures because a lock that isn't taken is released in nested event loops. Looking at the first parameter is already done by co_wrappers to decide where the coroutine should run, so doing the same in no_co_wrappers is only consistent. Take the lock in the generated bottom halves to fix the problem. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230525124713.401149-2-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
d6ee2e324e |
block-coroutine-wrapper: Introduce no_co_wrapper
Some functions must not be called from coroutine context. The common pattern to use them anyway from a coroutine is running them in a BH and letting the calling coroutine yield to be woken up when the BH is completed. Instead of manually writing such wrappers, add support for generating them to block-coroutine-wrapper. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230126172432.436111-2-kwolf@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
5b317b8dd9 |
block-coroutine-wrapper: support void functions
Just omit the various 'return' when the return type is void. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230113204212.359076-2-kwolf@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
e2c1c34f13 |
include/block: Untangle inclusion loops
We have two inclusion loops:
block/block.h
-> block/block-global-state.h
-> block/block-common.h
-> block/blockjob.h
-> block/block.h
block/block.h
-> block/block-io.h
-> block/block-common.h
-> block/blockjob.h
-> block/block.h
I believe these go back to Emanuele's reorganization of the block API,
merged a few months ago in commit
|
3 years ago |
|
|
e6d3f7a602 |
block-coroutine-wrapper.py: introduce annotations that take the graph rdlock
Add co_wrapper_bdrv_rdlock and co_wrapper_mixed_bdrv_rdlock option to
the block-coroutine-wrapper.py script.
This "_bdrv_rdlock" option takes and releases the graph rdlock when a
coroutine function is created.
This means that when used together with "_mixed", the function marked
with co_wrapper_mixed_bdrv_rdlock will support both coroutine and
non-coroutine case, and in the latter case it will create a coroutine
that takes and releases the rdlock. When called from a coroutine, the
caller must already hold the graph lock.
Example:
void co_wrapper_mixed_bdrv_rdlock bdrv_f1();
Becomes
static void bdrv_co_enter_f1()
{
bdrv_graph_co_rdlock();
bdrv_co_function();
bdrv_graph_co_rdunlock();
}
void bdrv_f1()
{
if (qemu_in_coroutine) {
assume_graph_lock();
bdrv_co_function();
} else {
qemu_co_enter(bdrv_co_enter_f1);
...
}
}
When used alone, the function will not work in coroutine context, and
when called in non-coroutine context it will create a new coroutine that
takes care of taking and releasing the rdlock automatically.
Example:
void co_wrapper_bdrv_rdlock bdrv_f1();
Becomes
static void bdrv_co_enter_f1()
{
bdrv_graph_co_rdlock();
bdrv_co_function();
bdrv_graph_co_rdunlock();
}
void bdrv_f1()
{
assert(!qemu_in_coroutine());
qemu_co_enter(bdrv_co_enter_f1);
...
}
About their usage:
- co_wrapper does not take the rdlock, so it can be used also outside
the block layer.
- co_wrapper_mixed will be used by many blk_* functions, since the
coroutine function needs to call blk_wait_while_drained() and
the rdlock *must* be taken afterwards, otherwise it's a deadlock.
In the future this annotation will go away, and blk_* will use
co_wrapper directly.
- co_wrapper_bdrv_rdlock will be used by BlockDriver callbacks, ideally
by all of them in the future.
- co_wrapper_mixed_bdrv_rdlock will be used by the remaining functions
that are still called by coroutine and non-coroutine context. In the
future this annotation will go away, as we will split such mixed
functions.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20221207131838.239125-17-kwolf@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
|
3 years ago |
|
|
6700dfb1b8 |
block-coroutine-wrapper.py: support also basic return types
Extend the regex to cover also return type, pointers included. This implies that the value returned by the function cannot be a simple "int" anymore, but the custom return type. Therefore remove poll_state->ret and instead use a per-function custom "ret" field. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20221128142337.657646-13-eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
0582fb8293 |
block-coroutine-wrapper.py: support functions without bs arg
Right now, we take the first parameter of the function to get the BlockDriverState to pass to bdrv_poll_co(), that internally calls functions that figure in which aiocontext the coroutine should run. However, it is useless to pass a bs just to get its own AioContext, so instead pass it directly, and default to the main loop if no BlockDriverState is passed as parameter. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20221128142337.657646-12-eesposit@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
76a2f554c1 |
block-coroutine-wrapper.py: introduce co_wrapper
This new annotation starts just a function wrapper that creates a new coroutine. It assumes the caller is not a coroutine. It will be the default annotation to be used in the future. This is much better as c_w_mixed, because it is clear if the caller is a coroutine or not, and provides the advantage of automating the code creation. In the future all c_w_mixed functions will be substituted by co_wrapper. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20221128142337.657646-11-eesposit@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
1bd542016c |
block: rename generated_co_wrapper in co_wrapper_mixed
In preparation to the incoming new function specifiers, rename g_c_w with a more meaningful name and document it. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20221128142337.657646-10-eesposit@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
3 years ago |
|
|
7d55a3bbad |
block-coroutine-wrapper.py: support BlockBackend first argument
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211006131718.214235-7-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> |
5 years ago |
|
|
bb43694872 |
block-coroutine-wrapper: allow non bdrv_ prefix
We are going to reuse the script to generate a nbd_ function in further commit. Prepare the script now. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20210610100802.5888-28-vsementsov@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com> |
5 years ago |
|
|
aaaa20b69b |
scripts: add block-coroutine-wrapper.py
We have a very frequent pattern of creating a coroutine from a function
with several arguments:
- create a structure to pack parameters
- create _entry function to call original function taking parameters
from struct
- do different magic to handle completion: set ret to NOT_DONE or
EINPROGRESS or use separate bool field
- fill the struct and create coroutine from _entry function with this
struct as a parameter
- do coroutine enter and BDRV_POLL_WHILE loop
Let's reduce code duplication by generating coroutine wrappers.
This patch adds scripts/block-coroutine-wrapper.py together with some
friends, which will generate functions with declared prototypes marked
by the 'generated_co_wrapper' specifier.
The usage of new code generation is as follows:
1. define the coroutine function somewhere
int coroutine_fn bdrv_co_NAME(...) {...}
2. declare in some header file
int generated_co_wrapper bdrv_NAME(...);
with same list of parameters (generated_co_wrapper is
defined in "include/block/block.h").
3. Make sure the block_gen_c declaration in block/meson.build
mentions the file with your marker function.
Still, no function is now marked, this work is for the following
commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200924185414.28642-5-vsementsov@virtuozzo.com>
[Added encoding='utf-8' to open() calls as requested by Vladimir. Fixed
typo and grammar issues pointed out by Eric Blake. Removed clang-format
dependency that caused build test issues.
--Stefan]
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
|
6 years ago |