From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwgOB-00015l-22 for qemu-devel@nongnu.org; Mon, 25 Sep 2017 23:18:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwgO7-0006R0-SM for qemu-devel@nongnu.org; Mon, 25 Sep 2017 23:18:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45500) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwgO7-0006Qo-Kn for qemu-devel@nongnu.org; Mon, 25 Sep 2017 23:18:23 -0400 Date: Tue, 26 Sep 2017 11:18:15 +0800 From: Peter Xu Message-ID: <20170926031815.GL19505@pxdev.xzpeter.org> References: <1506321449-24013-1-git-send-email-peterx@redhat.com> <1506321449-24013-2-git-send-email-peterx@redhat.com> <4540074c-f523-41f4-3ce7-8b6514060fa4@suse.de> <20170925081426.GE19505@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 1/4] qom: provide root container for internal objs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , "Daniel P . Berrange" , Stefan Hajnoczi , Fam Zheng , "Dr . David Alan Gilbert" , Markus Armbruster , Manos Pitsidianakis On Mon, Sep 25, 2017 at 11:00:33AM +0200, Andreas F=C3=A4rber wrote: > Hi, >=20 > Am 25.09.2017 um 10:14 schrieb Peter Xu: > > On Mon, Sep 25, 2017 at 09:14:21AM +0200, Andreas F=C3=A4rber wrote: > >> Am 25.09.2017 um 08:37 schrieb Peter Xu: > >>> We have object_get_objects_root() to keep user created objects, how= ever > >>> no place for objects that will be used internally. Create such a > >>> container for internal objects. > >>> > >>> CC: Andreas F=C3=A4rber > >>> CC: Markus Armbruster > >>> CC: Paolo Bonzini > >>> Suggested-by: Daniel P. Berrange > >>> Signed-off-by: Peter Xu > >>> --- > >>> 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); > >>> =20 > >>> /** > >>> + * 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. T= he 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"); > >>> } > >>> =20 > >>> +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 nam= e? > >=20 > > Hi, Andreas, > >=20 > > 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"). > >=20 > > Or, do you have any suggestion? > >=20 > > (I did think about something like "hidden-objects", but I believe the= y > > are not hidden as well if we think they are not internal...) >=20 > I'm on travels and only seeing this 1/4 without context - according to > Manos apparently something about IOThreads. >=20 > 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 t= o > an existing device, you could just place them somewhere outside > "/machine", e.g. directly in the root node or in a container specific t= o > 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. >=20 > 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 =3D=3D NULL to avoid breaking or modifyin= g QOM interfaces. Preparing another post. Thanks all! >=20 > Regards, > Andreas >=20 > --=20 > SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton > HRB 21284 (AG N=C3=BCrnberg) --=20 Peter Xu