On Mon, Sep 25, 2017 at 11:00:33AM +0200, Andreas Färber wrote:
> Hi,
>
> Am 25.09.2017 um 10:14 schrieb Peter Xu:
> > On Mon, Sep 25, 2017 at 09:14:21AM +0200, Andreas Färber wrote:
> >> Am 25.09.2017 um 08:37 schrieb Peter Xu:
> >>> We have object_get_objects_root() to keep user created objects, however
> >>> no place for objects that will be used internally. Create such a
> >>> container for internal objects.
> >>>
> >>> CC: Andreas Färber <afaer...@suse.de>
> >>> CC: Markus Armbruster <arm...@redhat.com>
> >>> CC: Paolo Bonzini <pbonz...@redhat.com>
> >>> Suggested-by: Daniel P. Berrange <berra...@redhat.com>
> >>> Signed-off-by: Peter Xu <pet...@redhat.com>
> >>> ---
> >>> include/qom/object.h | 10 ++++++++++
> >>> qom/object.c | 5 +++++
> >>> 2 files changed, 15 insertions(+)
> >>>
> >>> diff --git a/include/qom/object.h b/include/qom/object.h
> >>> index f3e5cff..f567052 100644
> >>> --- a/include/qom/object.h
> >>> +++ b/include/qom/object.h
> >>> @@ -1214,6 +1214,16 @@ Object *object_get_root(void);
> >>> Object *object_get_objects_root(void);
> >>>
> >>> /**
> >>> + * object_get_internal_root:
> >>> + *
> >>> + * Get the container object that holds internally used object
> >>> + * instances. This is the object at path "/internal-objects"
> >>> + *
> >>> + * Returns: the internal object container
> >>> + */
> >>> +Object *object_get_internal_root(void);
> >>> +
> >>> +/**
> >>> * object_get_canonical_path_component:
> >>> *
> >>> * Returns: The final component in the object's canonical path. The
> >>> canonical
> >>> diff --git a/qom/object.c b/qom/object.c
> >>> index 3e18537..857cee7 100644
> >>> --- a/qom/object.c
> >>> +++ b/qom/object.c
> >>> @@ -1370,6 +1370,11 @@ Object *object_get_objects_root(void)
> >>> return container_get(object_get_root(), "/objects");
> >>> }
> >>>
> >>> +Object *object_get_internal_root(void)
> >>> +{
> >>> + return container_get(object_get_root(), "/internal-objects");
> >>
> >> Whatever you expose in the QOM tree is no longer internal. Other name?
> >
> > Hi, Andreas,
> >
> > If you mean "info qom-tree" here, can we still treat it as internal?
> > Since after all it's not exposed in QMP (while IMHO QMP is the
> > official protocol for QEMU clients). And IIUC some HMP commands do
> > dump some internal structs for debugging purpose (like: "info
> > ramblock").
> >
> > Or, do you have any suggestion?
> >
> > (I did think about something like "hidden-objects", but I believe they
> > are not hidden as well if we think they are not internal...)
>
> I'm on travels and only seeing this 1/4 without context - according to
> Manos apparently something about IOThreads.
>
> The reason that certain container groups such as "/machine/peripheral"
> exist was more of a legacy reason for migration from qdev, so yes I am
> critical of "/hidden-objects" as well. If the objects are not related to
> an existing device, you could just place them somewhere outside
> "/machine", e.g. directly in the root node or in a container specific to
> that use case (/io? /threads?), rather than a new generic bucket of
> whatever name. Any objects not under /machine should be close to what
> you consider internal.
>
> Note that "info qom-tree" is not the only way to query the objects,
> there's some Python QMP scripts as well.
I see. I'll take away Stefan's suggestion to create a standalone
container for internal objects, so that it will be totally hidden.
I didn't choose to allow parent == NULL to avoid breaking or modifying
QOM interfaces.
Preparing another post. Thanks all!
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
--
Peter Xu
