Peter Memishian wrote:
> > Is there any reason not to design in that capability now?
> > Especially as a large slice of our hardware already could support it.
> > If we can distinguish between factory and current mac address for the
> > purpose of "get", why can't we do the same for "set"?
>
> The libdlpi APIs are being designed within the scope of DLPI and DLPI does
> not provide such a capability. Thus providing a way to "set" the
> "factory" mac address, other than via DLPI would be out of the scope of
> this library.
I think Darren's general point that we will likely need to be able to set
other MAC addresses in the future is valid -- especially with the multiple
MAC address support that recently went back into Nevada (PSARC/2006/265).
While DLPI isn't rich enough to allow more than DL_CURR_PHYS_ADDR to be
set today (AFAIK), it would be a shame to have to add another libdlpi
function later because we didn't plan ahead. In fact, I'm not convinced
that even dlpi_get_physaddr()'s `type' field would be sufficient to handle
this case, since the number of MAC addresses that may need to be set or
retrieved is unbounded.
Rajagopal, could you comment on what you had in mind for how DLPI will
interact with multiple MAC address support in the future?
Multiple MAC addresses are going to be used by virtual NICs. When a
virtual NIC is
created, it is going to use the interface provided by PSARC/2006/265
(multiple MAC
address support) to add or reserve a MAC address. Once an address is
added/reserved
by the virtual NIC, that is the MAC address that is exposed to its
clients. All DLPI
operations will be on this virtual NIC, and as such
dlpi_get/set_physaddr() would
continue to work. When an address is added/reserved, the slot ID is
returned. Virtual
NIC will use this ID to set a new address.
Question is what scenario would you need for dlpi to have the NIC
return all its mac
addresses?
-krgopi
_______________________________________________
networking-discuss mailing list
[email protected]
