> > So what is the intended purpose of mci_name? Clearly it is not to uniquely > > identify an object. > > right now there is a kstat and flow name that's tied with this. all of > these get renamed together. as long as the mac client doesn't call > mac_unicast_add(), the kstat won't be created. the flow name doesn't > matter since this is an internal, not user-defined, flow.
This seems pretty fragile -- e.g., it is not at all obvious that introducing a mac_unicast_add() call can cause kstat problems because of previously-overlapping mac client names. Also, if the flow name doesn't matter, why are we assigning a name at all? It also seems odd that this name is serving double-duty, as it's alternately either provided by the consumer of the client API or set by mac_client_open() to something that may be of interest to the consumer (such as the associated datalink). One alternative would be to have the name always identify the consumer (mci_client_user or whatever) and have mci_name always identify the associated datalink, and internally use the concatenation of mci_client_user and mci_name name the various related objects like kstats and flows. -- meem
