Re: [PATCH V5 04/13] blockdev: Update tracking iothread users with holder name

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On Tue, Mar 10, 2026 at 06:02:54PM +0800, Zhang Chen wrote:
> On Mon, Mar 9, 2026 at 4:15 PM Stefan Hajnoczi <stefanha@redhat.com> 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 <zhangckid@gmail.com>
> > > ---
> > >  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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]