>> Hi, >> >> I am thinking to add a function >> >> int mac_open_by_linkid(dladm_linkid_t linkid, mac_handle_t *mhp); >> >> This function takes linkid as the input argument because: >> >> 1. As part of vanity naming project, one will be able to specify the vanity >> link name when creating an aggregation. >> >> 2. As we already discussed in our design, that even the link name changes, >> the aggregation created over it will not be affected. In that case, the >> linkid will be the only long-live identifier of a link. >> >> 3. As I talked to the LDOM person (the discussion is still going on), I >> believe that LDOM manager specifies a link name too, and I expect other MAC >> consumers like VNIC will also take the link name. So that I think >> mac_open_by_linkid() could be convenient for others to use. >> >> I'd like to hear your opinion. >> > > does that mean aggr would now have to first lookup the linkid from the > linkname using some other function and then call your mac_open_by_linkid()? > can you just do the linkid lookup from within the old mac_open()? > or are you thinking of doing the translation from userland? > Actually, because we already decided that a rename-link operation won't affect an already established aggregation, so that an aggr_grp_t only keeps linkid instead of link name.
So yes, this translation is in the user land. >> My another question is whether we need to keep the old mac_open() function. >> > > I think keeping it would give kernel clients more flexibility (i.e. either > linkid or linkname could be passed from userland) > So that is mac_open_by_linkname(). But today mac_open() takes mac name. I am thinking of removing that one. Also, even in the kernel, it is only one function call to translate linkname to linkid, I am still not convinced why we need to keep mac_open_by_linkname(). >> The only place left in ON that is calling mac_open() and cannot be changed >> to call the new form of function is in strplumb.c, when it tries to get a >> mac address of a GLDv3 device. (see below). I don't know whether I could >> just simply remove it, as the logic below that (which is for legacy >> devices) can do the right thing. >> > > it's safe to remove mac_open() from strplumb. s10 code doesn't have it. > Okay. Thank you! - Cathy
