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. (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. 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. It's a combination of this architectural conflict (the ioctl makes high level design assumptions that are simply untrue on Solaris) and the plain ugliness of that ioctl that've held it back in the past. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
