Sagun Shakya wrote:
Thank you for reviewing the documents. Please see my responses inline.
Darren Reed wrote:
Reading through the man pages, there should be some linking between
DLPI_CURR_PHYS_ADDR in dlpi_get_phyaddr() and dlpi_set_physaddr().
Which one does dlpi_set_physaddr() change the return value for?
dlpi_set_physaddr() changes the return value for DL_CURR_PHYS_ADDR and
I will include that in the the dlpi_setphysaddr() manpages.
Thanks.
In addition, should there be some mention of any interaction between
this and local-mac-address? Whilst this may be part of the EEPROM,
and not an official interface, it is a very well known knob.
Also, correct me if I'm wrong, but isn't there some SPARC hardware
where the MAC address is a (derived) property of the system and not
the NIC itself?
And in these cases, although it is initially set in the factory, it
is changable - is it unreasonable to ask for a method to set it as well?
It is correct that on the sparc systems, if "local-mac-address" is set
to false in the EEPROM the network drivers uses the system-wide ethernet
address. However, this is not part of DLPI and only sparc specific,
providing such a method in a public library would not provide a
consistent approach.
Hmmm, you've misunderstood what I was getting at so maybe I didn't
convey the message very well.
I wasn't intending to say that there should be an interface through DLPI
to local-mac-address, but rather it is conceivably possible to change
the returned MAC address for "factory" using software.
Also, are there no NICs in existance that allow software to change
their factory set address?
If there are, should there be scope to support that with libdlpi
(even if we don't support it now) or is changing the factory address
something we don't want to ever support through this interface?
If in the future, Solaris or DLPI specification changes to allow the
factory default address to be changed support can be added to the
libdlpi api.
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"?
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
