From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f856C-0002r2-Hl for qemu-devel@nongnu.org; Mon, 16 Apr 2018 10:27:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8569-0003hs-CR for qemu-devel@nongnu.org; Mon, 16 Apr 2018 10:27:16 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:45812 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f8569-0003hU-5X for qemu-devel@nongnu.org; Mon, 16 Apr 2018 10:27:13 -0400 Date: Mon, 16 Apr 2018 16:27:06 +0200 From: Igor Mammedov Message-ID: <20180416162706.43212a69@redhat.com> In-Reply-To: References: <20180329032149.44685-1-aik@ozlabs.ru> <20180416152040.7b88b902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu] RFC: memory/hmp: Print owners/parents in "info mtree" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexey Kardashevskiy , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Markus Armbruster On Mon, 16 Apr 2018 15:30:39 +0200 Paolo Bonzini wrote: > On 16/04/2018 15:20, Igor Mammedov wrote: > > Generally object doesn't need to know its own name, > > we use it only for debugging and nice error reporting so far. > > I'd rather have 'id' property at Object level so we won't have > > to fish out ID from parent /which we aren't supposed to do and > > which doesn't work in some cases/ when it's needed within > > object itself. > > Having an 'id' at object level is also a mess, because that id is > invalid after unparent. I'd just consider 'id' as object name which is valid even if there is no parent (during whole object lifecycle). That would allow for object to have a reachable name vs getting NULL when parent isn't set. Maybe Object::id is overkill, but we probably could use NamedObject where it's needed and avoid reverse engineering id from path. > Since this is just for debugging use, > object_get_canonical_path_component is the right function. We can just > make it return NULL if there is no parent. looking at current use it out-grew just debugging usecases and it's rather messy right now: ram_backend_memory_alloc, throttle_group_obj_complete, xlnx_zynqmp_create_rpu, spapr_drc.c:realize, iothread_complete, memory_region_name > Paolo