On 16/04/2018 16:27, Igor Mammedov wrote: > On Mon, 16 Apr 2018 15:30:39 +0200 > Paolo Bonzini <pbonz...@redhat.com> 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).
What's the point of an object name if it cannot be unique? Paolo > 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 I agree, _but_ it's definitely okay for debugging usecases. Paolo
