UNIX System Administration Handbook - Evi Nemeth [156]
# cd /dev
# ./MAKEDEV pty
12.10 NAMING CONVENTIONS FOR DEVICES
Naming conventions for devices are somewhat random. They are often holdovers from the way things were done on a DEC PDP-11.
For devices that have both block and character identities, the character device name is usually prefaced with the letter r for “raw” (e.g., /dev/da0 vs. /dev/rda0). An alternative convention is to store character device files in a subdirectory that has a name that starts with r (e.g., /dev/dsk/dks0d3s0 vs. /dev/rdsk/dks0d3s0). However, an r does not always imply a raw device file.
Serial device files are usually named tty followed by a sequence of letters that identify the interface the port is attached to. Sometimes, a TTY is represented by more than one device file; the extra files usually provide access to alternative flow control methods or locking protocols.
See Chapter 7 for more information about serial ports.
BSD disk names often begin with a two-letter abbreviation for either the drive or the controller, followed by the drive number and partition name. For example, da0a is the block device that represents the a partition of the first disk drive on a SCSI controller; rda0a is the corresponding character device.
The names of tape devices often include not only a reference to the drive itself but also an indication of whether the device rewinds after each tape operation and the density at which it reads and writes. Each vendor has a different scheme.
Table 12.9 lists some typical names for common devices (disk and CD-ROM drives) on our example systems.
Table 12.9 Device naming conventions for disks and CD-ROM drives
a. A = controller number, B = SCSI ID, L = unit letter, N = unit number, P = partition letter or number
12.11 LOADABLE KERNEL MODULES
Loadable kernel modules have come a long way since the last revision of this book. Among our example systems, Solaris, Linux, and FreeBSD all support kernel modules, although the degree of support varies widely. Solaris is a very modular kernel, Linux is pretty modular, and FreeBSD barely supports kernel modules at all.
LKM support allows a device driver—or any other kernel service—to be linked into and removed from the kernel while it is running. This facility makes the installation of drivers much easier, since the kernel binary does not need to be changed. It also allows the kernel to be smaller because drivers are not loaded unless they are needed.
Loadable modules are implemented by providing one or more documented “hooks” into the kernel that additional device drivers can grab onto. A user-level command communicates with the kernel and tells it to load new modules into memory. There is usually a command that unloads drivers as well.
Although loadable drivers are convenient, they are not entirely safe. Any time you load or unload a module, you risk causing a kernel panic. We don’t recommend loading or unloading an untested module when you are not willing to crash the machine.
Like other aspects of device and driver management, the implementation of loadable modules is OS dependent. The sections below outline the commands and caveats appropriate for Solaris, Linux, and FreeBSD.
Loadable kernel modules in Solaris
In Solaris, virtually everything is a loadable module. The modinfo command lists the modules that are currently loaded.
The output looks like this:
# modinfo
Id Loadaddr Size Info Rev ModuleName
1 ff07e000 3ba0 1 1 specfs (filesystem for specfs)
2 ff086000 1340 - 1 swapgeneric (root/swap config)
3 ff082000 1a56 1 1 TS (time sharing sched class)
4 ff084000 49c - 1 TS_DPTBL (Timesharing dispatch)
5 ff095000 15248 2 1 ufs (filesystem for ufs)
6 ff0b8000 20e0 1 1 rootnex (sun4c root nexus)
7 ff084a00 170 57 1 options (options driver)
8 ff08dc00 2f4 62 1 dma (Direct Memory Access)
9 ff08c000 968 59 1 sbus (SBus nexus driver)
...
On our Solaris system, the list continued for 80-odd lines. Many elements that are hardwired into the kernel on other versions of UNIX (such as UFS, the local filesystem) are loadable drivers