> > > > For debug information, could we output the resource name instead? (I > > > > realize that this may contain the linkid, depending on the outcome of > > > > the discussion above). > > > > > > > I've tried to outcome the resource name as much as possible. But some > > of the > > > debug information cannot be changed. For example, in > > aggr_offline_port(): > > > > > > rcm_log_message(RCM_TRACE2, "AGGR: delete aggregation %u\n", > > > aggr->da_aggrid); > > > > I presume we don't have the information at this point to map it back to a > > linkname (has that info already been deleted)? > > > The <link name, linkid> mapping is still stored in the dlmgmtd daemon, > and we could get the link name if we really need it. But I am not > convinced that we need it, as the message is really for diagnose > purpose, calling libdladm APIs to convert linkid to linkname seems > overkilled.
OK. > > > I don't think we ever call rcm_notify_event(RCM_RESOURCE_LINK_NEW) with > > the > > > locks held. Did you see any code does that? > > > > No, but I'm questioning your original comment that it would be unsafe to > > hold the lock when calling rcm_notify_event(RCM_RESOURCE_LINK_NEW). Seems > > like this wouldn't be a problem even if we did hold the lock because the > > handling of the notification is performed asynchronously. > > > The notification could be synchronous if it is called within the rcm_daemon. > See > rcm_direct_call(). OK. > > > > > The aggr_unregister() function does not seem to be called at all. > > So that I > > > > > am not sure whether 221-227 could have work to do. But at this > > point, since > > > > > the framework does not provide the rcm_handle, it is not possible > > to call > > > > > rcm_unregister_interest() here. > > > > > > > > As above, please add a comment (and file the bug). > > > > So was the bug filed? > > > 6642490. Thanks. -- meem
