> > I've noticed that dlpi_walk(3dlpi) will include etherstub devices in > > it's iteration of network devices which seems reasonable enough. If > > you then try to a dlpi_info(3dlpi), it appears that the mactype is > > showing up as DL_ETHER. However, either a dlpi_bind or dlpi_enabmulti > > fail (I haven't had a chance to narrow it down yet) on etherstub > > devices (again seems reasonable). So how can one distinguish > > (programmatically) between etherstubs (as I'd prefer to just ignore > > them), and links (I don't need to distinguish between vnics and > > regular links)? > > > 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. > > Also, I noticed that even if I create a vnic, assign it to an > > exclusive-ip zone, and then try a dlpi_walk within that zone, that the > > interface does not show up, but still shows up and can be accessed > > (dlpi_bind, etc.) from the global zone. Should that be the case (this > > is all on SXCE b105)? > > > dlpi_walk() is used to walk all DLPI links, no matter which zone they > belong to. To walk the DLPI links in a specific zone, one can call > zone_list_datalink(), but that is not a committed interface. Seems like there should also be a public interface for this, e.g., dlpi_zone(). This does start to beg the question of whether we want to continue to put all of the public datalink functionality in libdlpi or whether other libraries like libdladm should fill this need. -- meem _______________________________________________ networking-discuss mailing list [email protected]
