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?
Whilst I didn't have multiple MAC addresses in mind, my concern
is that the "set" should be called in the same way as "get", even if
there is (currently) only a single parameter that works with "set".
Maybe in the future there will be a DLPI mechanism to change the
factory address or there will be a 3rd setting...who knows? If we
are opening up get like this, it stands to reason we should make
some plans for set as well.
Otherwise, if all that is being proposed now is all that ever will be,
we might want to consider having pushing the "type" into the name
of the function, have two gets and one set. This removes any
ambiguity that might exist from the current set function whilst
leaving the path open to handle more physical address types by
expanding the API.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
