On Fri, Aug 14, 2009 at 01:29:53AM -0700, Peter Memishian wrote: > > > > 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? >
the flow name is there because it will be used for creating the kstat in case mac_unicast_add() gets called. yes, this sounds a bit convoluted. (the code is: mac_client_open()->mac_flow_create() creates an empty flow at some point later mac_unicast_add()->mac_client_datapath_setup()->... mac_flow_create() is called again to create the kstat) > 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. > sounds like this could work. eric
