Peter Memishian writes: > > In current Nevada, it recognize the etherstub links by calling > > dladm_name2info() and see whether the class of the link is > > DATALINK_CLASS_ETHERSTUB. > > > > In my own opinion, etherstubs cannot be used as normal DLPI devices > > anyway, so it is probably better to just exclude them from dlpi_walk(). > > I think there should be *some* way to see all DLPI devices from > dlpi_walk(). We could introduce a DLPI_ETHERSTUB flag, or we could > introduce a new public dlpi_class() function that returned the link's > class and allowed the caller to decide, or perhaps both.
For what it's worth, we've also had a small amount of trouble in the bridging code dealing with these interfaces-that-are-but-aren't- really-Ethernet. A better answer for the long term would be to make them behave the same as regular old Ethernet, including having a primary client and MAC address. I'm guessing that'll probably be more work, though. -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
