On Thu, Mar 12, 2026 at 03:05:55PM +0800, Zhang Chen wrote:
> 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.

I'm not sure if we are talking about the same thing, but when the QAPI
schema is modified to use an enum it would also be necessary to modify
the C API:

iothread_get_aio_context() and iothread_put_aio_context() would take a
struct IOThreadHolder instead of a const char *holder argument.

Stefan

Attachment: signature.asc
Description: PGP signature

Reply via email to