From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaMII-0001nz-43 for qemu-devel@nongnu.org; Fri, 11 Sep 2015 07:15:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaMIE-0006Rx-36 for qemu-devel@nongnu.org; Fri, 11 Sep 2015 07:15:02 -0400 References: <1441400485-29167-1-git-send-email-marcandre.lureau@redhat.com> <55EDB16B.6080205@suse.de> <55F2A942.4040500@msgid.tls.msk.ru> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <55F2B7AF.1060306@suse.de> Date: Fri, 11 Sep 2015 13:14:55 +0200 MIME-Version: 1.0 In-Reply-To: <55F2A942.4040500@msgid.tls.msk.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qom/object.h: remove some child/parent doc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-trivial@nongnu.org, marcandre.lureau@redhat.com, qemu-devel@nongnu.org Am 11.09.2015 um 12:13 schrieb Michael Tokarev: > 07.09.2015 18:46, Andreas F=C3=A4rber wrote: >> Am 04.09.2015 um 23:01 schrieb marcandre.lureau@redhat.com: >>> From: Marc-Andr=C3=A9 Lureau >>> >>> It looks like this documentation is obsolete: a child object may look= up >>> its parent stored in the Object struct. >>> >>> Signed-off-by: Marc-Andr=C3=A9 Lureau >>> --- >>> include/qom/object.h | 3 --- >>> 1 file changed, 3 deletions(-) >> >> Either once again you are trying to do stuff behind my back, or your >> setup is really broken: I double-checked that include/qom/ is listed i= n >> MAINTAINERS, so I should've been CC'ed rather than just -trivial. >> >> It's been a valid rule not to mess with these internal fields, therefo= re >> this is not trivial at all, and that's one reason why my x86 CPU serie= s >> using it was an RFC. We should either come up with a proper wrapper >> function object_get_parent(), or with a wrapper function adding a link= <> >> property (where we would need to be careful with ref counts) - long ti= me >> only the composition tree needed to mess with an object's parent. >> >> If you have a concrete use case of parent access, please point to it. >=20 > So, should the current documentation remain, or should the patch be > applied? If the latter, Andreas, please take care of it. This patch should not be applied, NACK. I outlined ideas for a v2 series above though. Thanks, Andreas >=20 > Thanks, >=20 > /mjt >=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)