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().
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.
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]
