On Fri, Sep 22, 2017 at 05:14:30PM +0800, Peter Xu wrote:
> On Fri, Sep 22, 2017 at 10:04:33AM +0100, Daniel P. Berrange wrote:
> > On Fri, Sep 22, 2017 at 04:56:10PM +0800, Peter Xu wrote:
> > > IOThread is a general framework that contains IO loop environment and a
> > > real thread behind. It's also good to be used internally inside qemu.
> > > Provide some helpers for it to create iothreads to be used internally.
> > >
> > > Signed-off-by: Peter Xu <pet...@redhat.com>
> > > ---
> > > include/sysemu/iothread.h | 8 ++++++++
> > > iothread.c | 21 +++++++++++++++++++++
> > > 2 files changed, 29 insertions(+)
> > >
> > > diff --git a/include/sysemu/iothread.h b/include/sysemu/iothread.h
> > > index d2985b3..b07663f 100644
> > > --- a/include/sysemu/iothread.h
> > > +++ b/include/sysemu/iothread.h
> > > @@ -46,4 +46,12 @@ AioContext *iothread_get_aio_context(IOThread
> > > *iothread);
> > > void iothread_stop_all(void);
> > > GMainContext *iothread_get_g_main_context(IOThread *iothread);
> > >
> > > +/*
> > > + * Helpers used to allocate iothreads for internal use. These
> > > + * iothreads will not be seen by monitor clients when query using
> > > + * "query-iothreads".
> > > + */
> > > +IOThread *iothread_create(const char *id, Error **errp);
> > > +void iothread_destroy(IOThread *iothread);
> > > +
> > > #endif /* IOTHREAD_H */
> > > diff --git a/iothread.c b/iothread.c
> > > index 44c8944..74e400c 100644
> > > --- a/iothread.c
> > > +++ b/iothread.c
> > > @@ -354,3 +354,24 @@ GMainContext *iothread_get_g_main_context(IOThread
> > > *iothread)
> > >
> > > return iothread->worker_context;
> > > }
> > > +
> > > +static Object *iothread_get_internal_parent(void)
> > > +{
> > > + return container_get(object_get_root(), "/internal-iothreads");
> > > +}
> >
> > I tend to think we might benefit from having this generalized in the
> > QOM API instead. We have object_get_objects_root() for things that
> > are created by the mgmt app / user via CLI / QMP. A parallel method
> > object_get_internal_root() could be useful for cases like this where
> > we want to create user-creatable objects, but not have them be
> > visible to the mgmt app / user, as that would confuse the mgmt app.
> >
> > Example for this scenario - libvirt calls query-iothreads to identify
> > IO thread PIDs, and would get very unhappy if the IOThread used by
> > the monitor would appear in that response, which is why Peter has
> > put it under /internal-iothreads. I think this scenario will apply
> > more broadly, so benefit from us having a general helper in QOM.
>
> Yeah, I can split the patch if we want it to be exposed to public.
>
> In that case, would the name "object_get_internal_root" be good?
Yeah that's fine with me, but lets see if Paolo has any thoughts from
the QOM side.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
