| Message ID | 20220121170544.2049944-26-eesposit@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block layer: split block APIs in global state and I/O | expand |
On 21.01.22 18:05, Emanuele Giuseppe Esposito wrote: > Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> > --- > include/block/block_int-common.h | 67 +++++++++++++++++++------------- > 1 file changed, 40 insertions(+), 27 deletions(-) > > diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h > index e007dbf768..cc8c8835ba 100644 > --- a/include/block/block_int-common.h > +++ b/include/block/block_int-common.h > @@ -815,12 +815,16 @@ struct BdrvChildClass { > */ > bool parent_is_bds; > > + /* > + * Global state (GS) API. These functions run under the BQL lock. > + * > + * See include/block/block-global-state.h for more information about > + * the GS API. > + */ > void (*inherit_options)(BdrvChildRole role, bool parent_is_format, > int *child_flags, QDict *child_options, > int parent_flags, QDict *parent_options); > - > void (*change_media)(BdrvChild *child, bool load); > - void (*resize)(BdrvChild *child); > > /* > * Returns a name that is supposedly more useful for human users than the The method this comment belongs to is `.get_name()`. It’s exposed through `bdrv_get_parent_name()`, which is called by `bdrv_get_device_name()` and `bdrv_get_device_or_node_name()` – so I think it should be classified as I/O. > @@ -837,6 +841,40 @@ struct BdrvChildClass { > */ > char *(*get_parent_desc)(BdrvChild *child); This function is very similar, so we might also want to reconsider classifying it as I/O. There’s no need, because all of its callers do run in the main thread, but at the same time I don’t believe there’s anything stopping us (and it starts to sound to me like all functions of the “get name” kind perhaps should ideally be I/O, in that they shouldn’t require the GS context). Up to you. O:) (Rest of this patch looks good!) Hanna
On 26/01/2022 13:42, Hanna Reitz wrote: > On 21.01.22 18:05, Emanuele Giuseppe Esposito wrote: >> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> >> --- >> include/block/block_int-common.h | 67 +++++++++++++++++++------------- >> 1 file changed, 40 insertions(+), 27 deletions(-) >> >> diff --git a/include/block/block_int-common.h >> b/include/block/block_int-common.h >> index e007dbf768..cc8c8835ba 100644 >> --- a/include/block/block_int-common.h >> +++ b/include/block/block_int-common.h >> @@ -815,12 +815,16 @@ struct BdrvChildClass { >> */ >> bool parent_is_bds; >> + /* >> + * Global state (GS) API. These functions run under the BQL lock. >> + * >> + * See include/block/block-global-state.h for more information about >> + * the GS API. >> + */ >> void (*inherit_options)(BdrvChildRole role, bool parent_is_format, >> int *child_flags, QDict *child_options, >> int parent_flags, QDict *parent_options); >> - >> void (*change_media)(BdrvChild *child, bool load); >> - void (*resize)(BdrvChild *child); >> /* >> * Returns a name that is supposedly more useful for human users >> than the > > The method this comment belongs to is `.get_name()`. It’s exposed > through `bdrv_get_parent_name()`, which is called by > `bdrv_get_device_name()` and `bdrv_get_device_or_node_name()` – so I > think it should be classified as I/O. Agree on this, and also on comment on patch 23 about bdrv_probe. > >> @@ -837,6 +841,40 @@ struct BdrvChildClass { >> */ >> char *(*get_parent_desc)(BdrvChild *child); > > This function is very similar, so we might also want to reconsider > classifying it as I/O. There’s no need, because all of its callers do > run in the main thread, but at the same time I don’t believe there’s > anything stopping us (and it starts to sound to me like all functions of > the “get name” kind perhaps should ideally be I/O, in that they > shouldn’t require the GS context). > > Up to you. O:) I understand what you mean, but I would like to leave it in global state. Seeing the assertion/definition as GS tells me that it is already under BQL, and I should not worry about I/O in that function. If no such assert was present, it would lead me to think that there might be I/O concurrently using it, and complicate the logic of whatever I want to do there. Thank you, Emanuele > > (Rest of this patch looks good!) > > Hanna >
diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h index e007dbf768..cc8c8835ba 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -815,12 +815,16 @@ struct BdrvChildClass { */ bool parent_is_bds; + /* + * Global state (GS) API. These functions run under the BQL lock. + * + * See include/block/block-global-state.h for more information about + * the GS API. + */ void (*inherit_options)(BdrvChildRole role, bool parent_is_format, int *child_flags, QDict *child_options, int parent_flags, QDict *parent_options); - void (*change_media)(BdrvChild *child, bool load); - void (*resize)(BdrvChild *child); /* * Returns a name that is supposedly more useful for human users than the @@ -837,6 +841,40 @@ struct BdrvChildClass { */ char *(*get_parent_desc)(BdrvChild *child); + /* + * Notifies the parent that the child has been activated/inactivated (e.g. + * when migration is completing) and it can start/stop requesting + * permissions and doing I/O on it. + */ + void (*activate)(BdrvChild *child, Error **errp); + int (*inactivate)(BdrvChild *child); + + void (*attach)(BdrvChild *child); + void (*detach)(BdrvChild *child); + + /* + * Notifies the parent that the filename of its child has changed (e.g. + * because the direct child was removed from the backing chain), so that it + * can update its reference. + */ + int (*update_filename)(BdrvChild *child, BlockDriverState *new_base, + const char *filename, Error **errp); + + bool (*can_set_aio_ctx)(BdrvChild *child, AioContext *ctx, + GSList **ignore, Error **errp); + void (*set_aio_ctx)(BdrvChild *child, AioContext *ctx, GSList **ignore); + + AioContext *(*get_parent_aio_context)(BdrvChild *child); + + /* + * 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 @@ -861,31 +899,6 @@ struct BdrvChildClass { * activity on the child has stopped. */ bool (*drained_poll)(BdrvChild *child); - - /* - * Notifies the parent that the child has been activated/inactivated (e.g. - * when migration is completing) and it can start/stop requesting - * permissions and doing I/O on it. - */ - void (*activate)(BdrvChild *child, Error **errp); - int (*inactivate)(BdrvChild *child); - - void (*attach)(BdrvChild *child); - void (*detach)(BdrvChild *child); - - /* - * Notifies the parent that the filename of its child has changed (e.g. - * because the direct child was removed from the backing chain), so that it - * can update its reference. - */ - int (*update_filename)(BdrvChild *child, BlockDriverState *new_base, - const char *filename, Error **errp); - - bool (*can_set_aio_ctx)(BdrvChild *child, AioContext *ctx, - GSList **ignore, Error **errp); - void (*set_aio_ctx)(BdrvChild *child, AioContext *ctx, GSList **ignore); - - AioContext *(*get_parent_aio_context)(BdrvChild *child); }; extern const BdrvChildClass child_of_bds;
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> --- include/block/block_int-common.h | 67 +++++++++++++++++++------------- 1 file changed, 40 insertions(+), 27 deletions(-)