Rafael Vanoni wrote:
> James Carlson wrote:
>
>> Rafael Vanoni writes:
>>
>>> The reasons for implementing SIOCGENADDR are, in no specific order:
>>> (a) get an interface's MAC address faster than taking the SIOCGARP way
>>> (b) provide a way for a non-privileged user to get it
>>> (c) interoperability with other systems (Linux, BSD,.. implement
>>> either SIOCGENADDR or equivalent)
>>>
>> All of them are indeed good reasons.
>>
>>
>>> There are a couple of RFEs relating to this, specifically
>>> http://bugs.opensolaris.org/view_bug.do?bug_id=4720634
>>>
>>> I'd like to run a couple of ideas by someone more experienced with
>>> ip_ic.c and this sort of thing. Anyone ?
>>>
>> The big problem with SIOCGENADDR (besides the staggeringly lousy name
>> -- are all interfaces Ethernet?!) is architecture: on those other
>> systems, network interfaces are not "plumbed" the way they are on
>> Solaris. They just exist, and it's somewhat reasonable to provide an
>> ioctl to give access to information about them. Those systems make
>> little or no distinction between network interface and IP interface.
>>
>> On Solaris, interfaces have to be plumbed in order for IP to know
>> something about them. A good implementation of SIOCGENADDR, though,
>> would work even if the user hasn't bothered to configure the interface
>> to work with IP. So, unless we hack around, we can't quite get a good
>> implementation.
>>
>
> Ok, that would be my suggestion but I'm new to this code, so hacking
> around isn't an option, if at all acceptable.
>
> Would it be reasonable to simply fail if an interface isn't plumbed? I
> don't have the specification for SIOCGENADDR, but I'd guess it doesn't
> cover (un)plumbed if's.
>
> We could follow the name/specification and make it so it would work only
> on Ethernet interfaces. But that would leave a whole for digging out
> non-ether addresses.
>
>
>> (There are many other places where this architectural difference shows
>> up. An obvious one is the split between ifconfig and dladm, which
>> makes a lot of sense on Solaris, but would be silly on those other
>> systems.)
>>
>> Plus, the IP-related ioctls are just that: IP. They're not the
>> datalink layer. The MAC layer address (how I detest "ENADDR" ...)
>> isn't an IP attribute, so it's passing strange to have an IP socket
>> and an IP ioctl in order to get non-IP data. I could live with that
>> as a trade-off, though, on just the compatibility benefit. In other
>> words, though it's weird, it'd be fine to violate layering here for
>> the greater good of portability.
>>
>
> I agree with you, those are very strong reasons not to have it and also
> that making IP reach over would be strange. But the reasons for doing it
> are also good, so it's a balanced situation.
>
>
>> The architecturally right way to do this on Solaris is to do it via
>> libdevinfo+DLPI or via libdladm+Nemo. I suppose IP could just "know"
>> about those interfaces, and reach over there for the requested
>> information, but it is a bit odd.
>>
>
> Do you see a performance difference between doing this with
> libdevinfo+DLPI or libdladm+Nemo ?
>
> And by using one of those libs, would we address (b) above ?
>
> Could we make ioctl reach directly to them, or would that be a
> unnecessary stretch ?
>
Architecturally, libdladm+Nemo is far superior. Not all network
interfaces are guaranteed to have a presence in the devinfo device tree,
and for those that do, the relationship is not guaranteed. (E.g.
imagine one physical device, with four ports, each of which is a
separate PPA, but which are tied to a single node in the device tree.)
Using libdladm you should be able to use DLPI methods to query MAC
addresses.
-- Garrett
> thanks
> Rafael
>
>
>
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
