On Thu, Mar 12, 2026 at 1:24 PM Stefan Hajnoczi <[email protected]> wrote: > > On Tue, Mar 10, 2026 at 06:02:54PM +0800, Zhang Chen wrote: > > On Mon, Mar 9, 2026 at 4:15 PM Stefan Hajnoczi <[email protected]> wrote: > > > > > > On Thu, Mar 05, 2026 at 10:24:50PM +0800, Zhang Chen wrote: > > > > Update the usage of "iothread_get_aio_context()". > > > > > > > > Signed-off-by: Zhang Chen <[email protected]> > > > > --- > > > > blockdev.c | 9 ++++++++- > > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/blockdev.c b/blockdev.c > > > > index 6e86c6262f..01ccf64b3f 100644 > > > > --- a/blockdev.c > > > > +++ b/blockdev.c > > > > @@ -3683,7 +3683,14 @@ void qmp_x_blockdev_set_iothread(const char > > > > *node_name, StrOrNull *iothread, > > > > goto out; > > > > } > > > > > > > > - new_context = iothread_get_aio_context(obj); > > > > + char *path = object_get_canonical_path(OBJECT(bs)); > > > > > > CCing Kevin and Markus in case they have an opinion on this. > > > > > > BlockDriverState is not a QOM Object so using OBJECT(bs) is undefined > > > behavior and may crash. > > > > > > node_name is unique across block driver graph nodes and could be used. > > > Unfortunately it's not connected to the QOM Object hierarchy. Maybe it's > > > best to build a holder name that is an invalid QOM path so there can be > > > no collisions between QOM paths and block driver graph nodes. > > > > > > g_autofree char *holder = g_strdup_printf("BlockDriverState %s", > > > node_name); > > > > > > (A cleaner long-term solution would be making BlockDriverStates QOM > > > Objects so they have a proper path.) > > > > If no other comments, it's OK for me. This issue like I mentioned in > > patch 7 and 9. > > A thought about the QAPI interface: > > QAPI expresses as much information in the schema as possible, so I think > the right approach would be a {'union': 'IOThreadHolder', > 'discriminator': 'type', ...} that supports at least "qom" and > "block-node". That way there are proper types to encode QOM Object paths > vs block node-names. Let's avoid having a single string value that takes > on different meaning depending on the type of holder.
In the iothread_get side: The same issue in the patch 8 (the node-name too), the point is qmp_xxxx_function input is a string. It's hard to track the QOM Object paths and the iothread. I will try to fill the gap. In the iothread_put side: * It looks like a pairing function is needed: + * qmp_x_blockdev_del_iothread() Patch 8 comments: + /* + * It seems we cannot find the corresponding resources + * (the iothread and path) when deleting them in qmp_block_export_del. + * The original method will be retained for the time being. + */ # @BlockExportOptions: # # Describes a block export, i.e. how single node should be exported on # an external interface. # # @type: Block export type # # @id: A unique identifier for the block export (across all export # types) # # @node-name: The node name of the block node to be exported # (since: 5.2) Thanks Chen
