Sebastien Roy wrote: > On 07/27/10 03:53 PM, [email protected] wrote: >> On (07/27/10 15:52), Sebastien Roy wrote: >>> One weird thing about all of this is that sockaddr_dl is used at the >>> link-layer, and our IP interface index concept doesn't exist at >>> that layer; >>> it's an IP interface concept. It's odd that the range of IP >>> interface index >> >> not that weird: sockaddr_dl is a socket address of type (sa_type >> and/or sdl_type) AF_LINK. That concept (as well as that of an interface >> index) is more general across diverse OS'es than "datalink_id_t". > > Yes, you're making my point. Solaris has no such general concept that > cuts across the layers of the stack, and so picking one that solely > exists at the IP layer isn't architecturally sane. For example, you can > operate on a link that isn't plumbed by IP using sockaddr_dl...
This point is more generally true for the whole idea of the BSD compatibility interfaces. There are many Solaris-specific bits that just plain do not translate well into the BSD universe. For example, the up/down flag on BSD applies to what we would call the "physical interface" -- if you mark it down, then the whole thing is down -- but on Solaris, the flag applies only to a single address. The BSD equivalent of up/down-ness is something we don't expose; it's really the union of the per-logical-interface IFF_UP flags. BSD doesn't use logical interfaces to represent addresses. Instead, addresses are just addresses -- you can have multiple addresses listed on a single given "interface." In Solaris, each address is a logical interface with its own distinct name and a subset of flags. BSD doesn't recognize plumbing as the same sort of normal administrative activity that Solaris does. You can (of course) hook new ifnets into the list, but the details of the behavior differ. BSD doesn't have separate IPv4 and IPv6 interfaces. It just has interfaces (more or less conforming to what we call "datalinks"), and you hang addresses (IPv4 or IPv6 or a combination) off of those interfaces. Solaris has an essentially arbitrary split between IPv4 and IPv6 down at the physical interface level, while all of the other per-address splits are at the logical interface level. This is of course an homage to DLPI, where the separate physical interfaces represent the separately bound "streams" on the driver for the different Ethertypes, but this detail of internal architecture profoundly affects how interfaces and addresses are represented on Solaris and how applications deal with them. BSD has for decades provided sa_len, so you don't have to guess at how long your sockaddrs really are. Solaris does not, and there's weird (and fragile) switch (sa.sa_family) in every application that has to deal with routing socket messages. And as you're pointing out, BSD doesn't really admit any distinction between IP and datalink layers. The distinction wasn't even very prominent in Solaris until fairly recently due to Clearview. I think the distinction is mostly good, but there are areas (such as mapping the bits properly into the interfaces and stacking MIBs) that look like they could use some investigation, because we're still coasting along on work that was done long ago and is likely no longer very accurate. Some important bits on BSD can be accessed only via sysctls. On Solaris, there are no sysctls, and you have to use either the STREAMS-based and undocumented "mib2" interfaces or the undocumented ndd bits to get at the same parts. In short, they're just plain different, and it's always been true that the BSD socket (particularly routing socket) semantics on Solaris have been different from "true" BSD. That difference is, in my opinion, ok, so long as (A) the simple, most basic and uncomplicated cases work the same enough on both Solaris and BSD that basic applications are mostly portable and (B) it's at least possible to write more complex software that functions properly on Solaris, even if it does take some work to do and litters your code with ifdefs. Making it function better in some of the existing edge cases would be nice, but I think it's a poor idea to hobble Solaris in pursuit of that goal. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
