On Tue, Feb 24, 2009 at 3:32 PM, Cathy Zhou <[email protected]> wrote: > On 2009?02?23? 10:02, Jason King wrote: >> >> 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().
Is dladm_name2info() a public interface? > >> 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. Are there any plans to raise the stability at all (or otherwise provide a way to obtain the information)? Also are there any plans for upgrading the stability of any of anything in libdladm? LLDP supports sending information about aggregrations, vlans, as well as other things -- which suggests a close relationship with [lib]dladm -- It could always periodically run dladm and parse the output it if need be, but why go through all that if it's not necessary. > > Thanks > - Cathy > >> If one wants to see a more concrete example, this is from testing the >> lld (link layer discovery) prototype I've been working on -- >> ssh://[email protected]/hg/lld/lld-proto2 or >> http://src.opensolaris.org/source/xref/lld/lld-proto2/ if you just >> want to browse. >> _______________________________________________ >> networking-discuss mailing list >> [email protected] > > _______________________________________________ networking-discuss mailing list [email protected]
