On Thu, Apr 12, 2007 at 06:46:06PM +0800, Cathy Zhou wrote: > 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? > 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) > 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. eric
