Artem Kachitchkine wrote: >> A nit: plumb/unplumb terminology has generally been restricted to IP >> interfaces rather than links (since IP interfaces actually have STREAMS >> modules associated with them). It'd be good if we could generally avoid >> using plumb/unplumb terminology with regard to links. > > OK. > >> > 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. -Seb
