On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito <eespo...@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
---
include/block/block_int-common.h | 51 ++++++++++++++++++++------------
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h
index 9857e775fe..ea16099c53 100644
--- a/include/block/block_int-common.h
+++ b/include/block/block_int-common.h
[...]
+ /*
+ * I/O API functions. These functions are thread-safe.
+ *
+ * See include/block/block-io.h for more information about
+ * the I/O API.
+ */
+
+ void (*resize)(BdrvChild *child);
+
/*
* If this pair of functions is implemented, the parent doesn't issue new
* requests after returning from .drained_begin() until .drained_end() is
@@ -859,23 +889,6 @@ struct BdrvChildClass {
*/
void (*activate)(BdrvChild *child, Error **errp);
int (*inactivate)(BdrvChild *child);
These are now I/O functions, but I believe they should be GS functions:
BlockBackend’s implementation for .activate (blk_root_activate())
invokes blk_set_perm(), which is a GS function. Its .inactivate
implementation (blk_root_inactivate()) invokes bdrv_child_try_set_perm().
(I also believe this makes sense in context: .activate is called by
bdrv_co_invalidate_cache(), which should be a GS function as I’ve
suggested in my reply to patch 20. .inactivate is called by
bdrv_inactivate_recurse(), which is a GS function, too.)
Hanna
