Prior to Solaris 2.6, sockets were an abstraction that existed at the library level. That is, much of the socket state and socket semantics support were provided within the libsocket library. The kernel's view of a process's socket connection entailed a file descriptor and linkage to a Stream head, which provided the path to the underlying transport. The disparity between the library socket state and the kernel's view was one of several reasons a new implementation was introduced in Solaris 2.6.

To provide a relevant basis for comparison, we'll start by looking at what happens in the pre-Solaris 2.6 release (that is, releases up to and including Solaris 2.5.1) when a socket is created. The major software layers are shown in Figure 1 for reference.

The primary software components are the socket library and the sockmod Streams module. The specfs layer is shown for completeness and is part of the layering, due to the use of pseudodevices as an entry point into the networking layers. To digress for a moment, the special filesystem, specfs, came out of SVR4 Unix as a means of addressing the issue of device special files that exist on Unix on-disk filesystems (e.g., UFS). Unix systems have always abstracted I/O (input/output) devices through device special files. The /dev directory namespace stores files that represent physical devices and pseudodevices on the system. Using device major numbers, those device files provide an entry point into the appropriate device driver, and using minor numbers, they are able to uniquely identify one of potentially many devices of the same type. (That is something of an oversimplification, but is sufficient for our purpose here in describing specfs.)

The /dev directory resides on the root filesystem, which is an instance of UFS. As such, references to the filesystem and its files and directories are handled using the UFS filesystem operations and UFS file operations. That is usually sufficient, but is not desired behavior for device special files. I/O to a device special file requires entry into a device driver. That is, issuing an open(2) system call on /dev/rmt/0 means someone wishes to open the tape device represented by /dev/rmt/0, thereby entering the appropriate driver's xx_open() routine. As a file on a UFS filesystem, the typical open routine called would be the ufs_open() code, but that's not what we want for devices. The specfs filesystem was designed to address such situations; it provides a straightforward mechanism for linking the underlying structures for file support in the kernel to the required device driver interfaces. Like all filesystems in Solaris (and any SVR4-based Unix) it's based on the VFS/vnode infrastructure. (See Solaris Internals and UNIX Internals in the Resources section for detailed information on VFS.)

Getting back to sockets in Solaris 2.5.1, the specfs layer comes

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine