> >> > This flag indicates that dld should use the provided MAC name > >> > instead of link ID. Before a device is fully attached, using > >> > vanity name services for mapping can be problematic. > >> > >> So why not always use the macname? Is it to handle VLAN link properties? > >> If so, I think that should sort itself out post-Crossbow since (as I > >> understand things) we'll have unique macnames for VLANs then. (I presume > >> that even if the macname is used, the property will be able to be located > >> using the eventual linkid associated with that macname.) > > > > I believe it has to do with some details of VLAN implementation in DLS. > > The initial Brussels case did use macname, but it was changed to linkid > > in "2008/056 Brussels addendum" as a result of Seb's code review comment: > > > > http://mail.opensolaris.org/pipermail/brussels-dev/2007-November/000582.html > > > > (search for "link_id_t") > > That was not the nature of my code-review comment. The initial Brussels > code, before that code-review, used link names (not MAC names). It is > not sensible to pass link names down to the kernel via an ioctl > interface, as the kernel has to translate that to either a datalink_id_t > or a MAC name in order to use access the GLDv3 kernel objects, both of > which would require a door upcall to userland to get.
So then could someone clarify why we must complicate the interface with two different forms of access (macname and linkid)? Is it because a macname is not unique for VLANs, and a linkid for the mac may not yet exist? If so, I guess we can live with the complexity until Crossbow integrates and then change things to always use a macname. That said, it's unclear to me whether Brussels handles link properties for VLANs and as such whether VLANs are germane to the discussion. -- meem
