This macro will be used to mark all coroutine_fn functions.
Right now, it will be used for the newly introduced coroutine_fn, since
we know the callers.

As a TODO, in the future we might want to add this macro to all
corotuine_fn functions, to be sure that they are only called in
coroutines context.

Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
 include/block/block-common.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/block/block-common.h b/include/block/block-common.h
index 297704c1e9..24de1d63fd 100644
--- a/include/block/block-common.h
+++ b/include/block/block-common.h
@@ -34,6 +34,17 @@
 #include "qemu/hbitmap.h"
 #include "qemu/transactions.h"
 
+/*
+ * QEMU_IN_COROUTINE
+ *
+ * To be used in all coroutine_fn functions, to make sure that the caller
+ * is always a coroutine.
+ */
+#define QEMU_IN_COROUTINE()                                         \
+    do {                                                            \
+        assert(qemu_in_coroutine());                                \
+    } while (0)
+
 /*
  * generated_co_wrapper
  *
-- 
2.31.1

Am 23.11.2022 um 12:42 hat Emanuele Giuseppe Esposito geschrieben:
> This macro will be used to mark all coroutine_fn functions.
> Right now, it will be used for the newly introduced coroutine_fn, since
> we know the callers.
> 
> As a TODO, in the future we might want to add this macro to all
> corotuine_fn functions, to be sure that they are only called in

s/corotuine_fn/coroutine_fn/

> coroutines context.
> 
> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>

I already asked about other opinions on this in patch 1.

These assertions are runtime checks and I don't feel they are the right
tool to verify coroutine_fn consistency. Asserting in tricky places
makes sense to me, especially as long as we can't rely on static
analysis, but adding it everywhere feels over the top to me.

Kevin

Il mer 23 nov 2022, 17:49 Kevin Wolf <kwolf@redhat.com> ha scritto:

> I already asked about other opinions on this in patch 1.
>
> These assertions are runtime checks and I don't feel they are the right
> tool to verify coroutine_fn consistency. Asserting in tricky places
> makes sense to me, especially as long as we can't rely on static
> analysis, but adding it everywhere feels over the top to me.
>

I agree that they don't seem necessary, since static analysis is possible
and superior.

Paolo


> Kevin
>
>