> > 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? -- meem _______________________________________________ networking-discuss mailing list [email protected]
