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 ? thanks Rafael _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
