2.3 Devices

One of the strengths of Unix is that users don't need to worry about the specific characteristics of devices and device I/O very often. They don't need to know, for example, what disk drive a file they want to access physically sits on. And the Unix special file mechanism allows many device I/O operations to look just like file I/O. As we've noted, the administrator doesn't have these same luxuries, at least not all the time. This section discusses Unix device handling and then surveys the special files used to access devices.

Device files are characterized by their major and minor numbers , which allow the kernel to determine which device driver to use to access the device (via the major number), as well as its specific method of access (via the minor number).

Major and minor numbers appear in place of the file size in long directory listings. For example, consider these device files related to the mouse from a Linux system:

$ cd /dev; ls -l *mouse
crw-rw-r--    1 root     root      10,  10 Jan 19 03:36 adbmouse
crw-rw-r--    1 root     root      10,   4 Jan 19 03:35 amigamouse
crw-rw-r--    1 root     root      10,   5 Jan 19 03:35 atarimouse
crw-rw-r--    1 root     root      10,   8 Jan 19 03:35 smouse
crw-rw-r--    1 root     root      10,   6 Jan 19 03:35 sunmouse
crw-rw-r--    1 root     root      13,  32 Jan 19 03:36 usbmouse

The major number for all but the last special file is 10; only the minor number differs for these devices. Thus, all of these mouse device variations are handled by the same device driver, and the minor number indicates the variation within that general family. The final item, corresponding to a USB mouse, has a different major number, indicating that a different device driver is used.

Device files are created with the mknod command, and it takes the desired device name and major and minor numbers as its arguments. Many systems provide a script named MAKEDEV (located in /dev), which is an easy-to-use interface to mknod.

2.3.1 An In-Depth Device Example: Disks

We'll use disk drives as an example in this overview discussion of Unix devices.^[14] As we've noted before, Unix organizes all user-accessible files into a single hierarchical directory structure. The files and directories it contains may be spread across several different disk drives.

^[14] This discussion will describe traditional ways of handling disks and filesystems. Unix versions that require or offer a logical volume manager do things quite differently at the lowest level, but this overview is still conceptually true for those systems (for "disk partition," read "logical volume"). See Chapter 10 for details.

On most Unix systems, disks are divided into one or more fixed-size partitions: physical subsets of the disk drive that are separately accessed by the operating system. There may be several partitions or just one on each physical disk. The disk partition containing the root filesystem is called the root partition and sometimes the root disk, although it obviously needn't comprise the entire disk drive. The disk containing the root partition is generally called the system disk.

The root filesystem is the first one mounted, early in the Unix boot process, and the remaining ones are mounted afterwards. On many operating systems, mounting a disk refers to the process of making the device's contents available. For Unix, it means something more. Like the overall Unix filesystem, the files and directories physically located on each disk partition are arranged in a tree structure.^[15] An integral part of the process of mounting a disk partition involves grafting its local directory structure into the overall Unix directory tree. Once this is done, the files physically residing on that device may be accessed via the usual Unix pathname syntax; Unix takes care of mapping pathnames to the correct physical device and data blocks.

^[15] For this reason, each separate disk partition may also be referred to as a filesystem. Thus, "filesystem" is used to refer both to the overall system directory tree (as in "the Unix filesystem"), comprising every user-accessible disk partition on the system, and to the files and directories on individual disk partitions (as in "build a filesystem on the disk partition" or "mounting the user filesystems"). Whether the overall Unix directory tree or an individual disk partition is meant will be clear from the context. On a related note, the terms partition and filesystem are often used synonymously. Thus, while technically only filesystems can be mounted, common usage often refers to "mounting a disk" or "mounting a partition."

For administrators, however, there are a few times when the disk partition must be accessed directly. The actual mount operation is the most common. Remember that disk partitions may be accessed in two modes, block mode and raw (or character) mode, and different special files are used from each mode. Character access mode does unbuffered I/O, generally making a data transfer to or from the device with every read or write system call. Block devices do buffered I/O on a block basis, collecting data in a buffer until the operating system can transfer an entire block of data at one time.

For example, the disk partition containing the root filesystem traditionally corresponded to the special files /dev/disk0a and /dev/rdisk0a, specifying the first partition on the first disk (disk 0, partition a), accessed in block and raw mode respectively,^[16] with the r designating raw device access.

^[16] The names given to the two types of special files are overdetermined. For example, the special file /dev/disk0a is referred to as a block special file, and /dev/rdisk0a is called a character special file. However, block special files are also sometimes called block devices, and character special files may be referred to as character devices or raw devices.

Most disk partition-related commands require a specific type of special file and won't accept the other kind.

Note that most Linux versions and newer versions of BSD do not distinguish between the two types of special files for IDE disks and provide only one special file per disk partition.

As an example of the use of special files to access disk partitions, consider the mount commands below:

# mount /dev/disk0a /
# mount /dev/disk1e /home

Naturally, the command to mount a disk partition needs to specify the physical disk partition to be mounted (mount's first argument) and the location to place it in the filesystem, its mount point (the second argument).^[17] Thus, the first command makes the files in the first partition on drive 0 available, placing them at the root of the Unix filesystem. The second command accesses a partition on drive 1, placing it at /home in the overall directory tree. Thus, regular files in the top-level directory on this second disk partition will appear in /home, and top-level directories on the disk partition become subdirectories of /home. The mount command is discussed in greater detail in Chapter 10.

^[17] In fact, on most Unix systems, mount is smarter than this. If you give it a single argument—either the physical disk partition or the mount point—it will look up the other argument in a table. But you can always supply both arguments, which means that you can rearrange your filesystem at will. (Why you would want to is a different question.)

2.3.1.1 Fixed-disk special files

Currently used special file names for disk partitions are highly implementation-dependent. However, a common logic underlies all of the various naming schemes. Disk special files can encode the type of disk, the disk controller, the disk location on its controller, and the disk partition within the physical disk (as well as the access mode) within the special file name.

Let's take the Tru64 special files for disks as an example; these special files have names of the following form, where n is the disk number (beginning at 0), and x is a letter from a to h designating the partition on the physical disk:

/dev/disk/dsknx

Block device

/dev/rdisk/dsknx

Character (raw) device

The partitions have conventional uses, and not all partitions are used on every disk (see Chapter 10 for more details). Traditionally, the a partition on the root disk contains the root filesystem. b partitions are conventionally used asswap partitions. On the root disk, other partitions might be used for various system directories: for example, e for /usr, h for /var, d for other filesystems, and so on.

The c partition often refers to the entire disk as a whole: every bit of space on the disk, including areas that should be accessed only by the kernel (such as the partition table at the beginning of the drive). For this reason, using the c partition for a filesystem was not allowed under older versions of Unix. More recent versions generally do not have this restriction.

System V-based systems use a similar naming philosophy, although the actual names differ. Special filenames for disk partitions are often of the form /dev/dsk/cktmdpsn, where k is the controller number, m is the drive number on that controller (often the SCSI target ID), and n is the partition (section) number on that drive (all numbers start at 0). p refers to the logical unit number (LUN) for SCSI devices and is thus usually 0. HP-UX uses this form but typically omits the s component.

In this scheme, character and block special files have the same names, but they are stored in two different subdirectories of /dev: /dev/dsk and /dev/rdsk, respectively. Thus, the special file /dev/dsk/c1t4d0s2 is the block special file for the third partition on the disk with SCSI ID 4 on controller 1 (the second controller). The corresponding character device is /dev/rdsk/c1t4d0s2.

Names in this format, known as controller-drive-section identifiers, are specified for all disk and tape devices under the System V.4 standard. Actual System V-based implementations start with this framework and may vary it somewhat according to the devices actually supported. Sometimes, they also provide links to more mnemonically or intuitively-named special files. For example, on some (mostly older) Solaris systems, /dev/sd0a might be linked to /dev/dsk/c0t3d0s0, allowing the conventional SunOS name to be used for the 0 partition on the disk with SCSI ID 3 on the first controller.^[18]

^[18] Even this isn't the full truth about Solaris special files. The files in /dev are usually links to the real device files in the /devices directory subtree.

Table 2-8 illustrates the similarities among disk special file names. The special files in the table all refer to a partition on the second SCSI disk drive on the first controller, using SCSI ID 4.

Table 2-8. Interpreting disk special file names

	FreeBSD	HP-UX	Linux	Solaris	Tru64[19]
Special file	/dev/rda1d	/dev/rdsk/c0t4d0	/dev/sdb1	/dev/rdsk/c0t4d0s3	/dev/rdisk/dsk1c
Raw access	/dev/rda1d	/dev/rdsk/c0t4d0	/dev/sdb1	/dev/rdsk/c0t4d0s3	/dev/rdisk/dsk1c
Device = Disk	/dev/rda1d	/dev/rdsk/c0t4d0	/dev/sdb1	/dev/rdsk/c0t4d0s3	/dev/rdisk/dsk1c
Type = SCSI	/dev/rda1d		/dev/sdb1
Controller #		/dev/rdsk/c0t4d0		/dev/rdsk/c0t4d0s3
SCSI ID		/dev/rdsk/c0t4d0		/dev/rdsk/c0t4d0s3
Device #	/dev/rda1d		/dev/sdb1		/dev/rdisk/dsk1c
Disk Partition	/dev/rda1d	assumed	/dev/sdb1	/dev/rdsk/c0t4d0s3	/dev/rdisk/dsk1c

^[19] Older Tru64 systems use the now-obsolete device names of the form /dev/rz*, /dev/ra*, and /dev/re*.

In yet another twist, systems that use logical volume managers (including AIX by default) allow the system administrator to specify names for the special files for logical volumes—virtual disk partitions—when they are created. These special files often have names of the form /dev/name, where name is chosen when the filesystem is created. On such systems, it is logical volumes rather than physical partitions that hold filesystems. We'll leave the rest of the gory details about these topics until Chapter 10.

2.3.2 Special Files for Other Devices

Other device types have special files named differently, but they follow the same basic conventions. Some of the most common are summarized in Table 2-9 (they will be discussed in more detail as appropriate in later chapters). In some cases, only the more commonly used form (block versus character) of the file is listed. For example, tape drives are seldom, if ever, accessed via the block device, and on many systems, the block special files do not even exist.

Table 2-9. Common Unix special file names

Device/use	Special file forms	Example
Floppy disk	/dev/[r]fdn* /dev/floppy	/dev/fd0
Tape devices[20] nonrewinding SCSI default tape drive	/dev/rmtn /dev/rmt/n /dev/nrmtn /dev/rstn /dev/tape	/dev/rmt1 /dev/rmt/0 /dev/nrmt0 /dev/rst0
CD-ROM devices	/dev/cdn /dev/cdrom	/dev/cd0
Serial lines	/dev/ttyn /dev/term/n	/dev/tty1 /dev/tty01 /dev/term/01
Slave virtual terminal (windows, network sessions, etc.)	/dev/tty[p-s]n /dev/pts/n	/dev/ttyp1 /dev/pts/2
Master/control virtual terminal devices	/dev/pty[p-s]n	/dev/ptyp3
Console device some System V AIX	/dev/console /dev/syscon /dev/lft0
Process controlling TTY (used to ensure I/O comes from/goes to terminal, regardless of any I/O redirection)	/dev/tty
Memory maps: physical kernel virtual	/dev/mem /dev/kmem
Mouse interface	/dev/mouse
Null devices: all output is discarded; reads return nothing (0 characters, 0 bytes) or a zero-filled buffer, respectively.	/dev/null /dev/zero

^[20] Tape devices often have suffixes that specify the tape density.

2.3.2.1 Commands for listing the devices on a system

Most Unix versions provide commands that make it easy to quickly determine what devices are present on the system, as well as their current status. Table 2-10 lists the commands for the systems we are considering.

Table 2-10. Device listing and information commands

Unix Version	Command(s)	Description
AIX	lscfg lscfg -v -l device lsdev -C -s scsi	List all devices. Device detail. List all SCSI IDs.
FreeBSD	dmesg	Boot messages identify all devices.
HP-UX	ioscan -f -n ioscan -f -n -C disk	Detailed device listing. Limit to device class.
Linux	dmesg lsdev scsiinfo -l lspci	Boot messages identify all devices. List major devices. List SCSI devices. List PCI devices.
Solaris[21]	getdev getdev type=disk devattr -v device	List devices. Limit to device class. Device detail.
Tru64	dsfmgr -s	List devices.

^[21] Although the getdev and devattr commands are included for completeness, they are often of limited use.

2.3.2.2 The AIX Object Data Manager

Under AIX, information about the devices on the system and other system configuration is stored in a binary database. The management apparatus for this database is known as theObject Data Manager (ODM), although "ODM" is also used colloquially to refer to the database itself, as well. Information is stored in the ODM as objects: items of various predefined types, with a collection of attributes and their associated sets or ranges of legal values.

Here is a textual representation of a sample entry for a disk drive:

name = "hdisk0"
status = 1
chgstatus = 2
ddins = "scdisk"
location = "00-00-0S-0,0"
parent = "scsi0"
connwhere = "0,0"
PdDvLn = "disk/scsi/1000mb"

This entry illustrates the general form for a device; most devices use the same fields, although their meaning varies somewhat depending on the device type. This entry describes a 1 GB SCSI disk drive.

The preceding entry came from the current devices database, stored in /etc/objrepos/CuDv. The attributes for this object (as well as those for the other objects on the system) are stored in a separate, current attributes database (found in /etc/objrepos/CuAt). This database may have several entries for any given object, one for each defined attribute for that class of object for which a nondefault value is set. For example, here are two of the attributes for the logical volume hd6 (one of the disk partitions on hdisk0):

name = "hd6" 
attribute = "type" 
value = "paging" 
type = "R" 
generic = "DU" 
rep = "s" 
nls_index = 639 
name = "hd6" 
attribute = "size" 
value = "16" 
type = "R" 
generic = "DU" 
rep = "r" 
nls_index = 647

The first entry indicates that this is a paging space, and the second indicates that its size is 16 logical partitions (64 MB, assuming the default partition size).

SMIT and the AIX commands it runs retrieve information from the ODM, as well as adding and modifying entries as necessary.

2.3.3 The Unix Filesystem Layout

Now that we've considered the Unix approach to major system components, it's time to acquaint you with the structure of the Unix filesystem. This brief tour will begin with the root directory and its most important subdirectories.

The basic layout of traditional Unix filesystems is illustrated in Figure 2-4, which shows an idealized directory structure (actually a superset of the items found on any one system). Note that in practice, there are lots of variations with respect to this paradigm.

Figure 2-4. Generic Unix directory structure

You'll find small deviations from this on most Unix systems you encounter, but the basic structure will be quite similar. We'll consider each of the major directories in turn.

2.3.4 The Root Directory

This is the base of the filesystem's tree structure; all other files and directories, regardless of their physical disk locations, are logically contained underneath the root directory (described in detail in Chapter 10).

There are a variety of important first-level directories under the / directory:

/bin

The traditional location for executable (binary) files for the various Unix user commands and utilities. On many current systems, some files within /bin are merely symbolic links to files in /usr/bin, and /bin is sometimes a link to /usr/bin. Other directories that hold Unix commands are /usr/bin and /usr/ucb.

/dev

The device directory, containing special files as described previously. The /dev directory is divided into subdirectories in most System V-based versions of Unix, with each subdirectory holding special files of a given type. Subdirectory names indicate the type of devices it contains: dsk and rdsk for disks accessed in block and raw mode, mt and rmt for tape drives, term for terminals (serial lines), pts and ptc for pseudo-terminals, and so on.

Solaris introduces a new device directory tree, beginning at /devices, and many files under /dev are links to files in subdirectories of /devices.

/etc and /sbin

System configuration files and executables. These directories contain many administrative files and configuration files. Among the most important files are the System V-style boot script subdirectories, named rcn.d and init.d, which are located under one of these two locations on systems using this style of booting.

/etc also traditionally contained the executable binaries for most administrative commands. In recent Unix versions, these files have moved to /sbin and /usr/sbin. Conventionally, the former is used for files required to boot the system, and the latter contains all other administrative commands.

On many systems, /etc also contains a subdirectory default, which holds files containing default parameter values for various commands.

On Linux systems, the sysconfig subdirectory holds network configuration and other package-specific, boot-related configuration files.

Under AIX, /etc contains two additional directories of note: /etc/objrepos stores the device configuration databases, and /etc/security stores most security-related configuration files.

/home

This directory is a conventional location for users' home directories. For example, user chavez's home directory is often /home/chavez. The name is completely arbitrary, however, and is often changed by the local site. It may also be a separate filesystem.

/lib

Location of shared libraries required for booting the system (i.e., before /usr is mounted).

/lost+found

Lost files directory. Disk errors or incorrect system shutdown may cause files to become lost: lost files refer to disk locations that are marked as in use in the data structures on the disk, but that are not listed in any directory (i.e., an inode with a link count greater than zero that isn't listed in any directory). When the system is booting, it runs a program called fsck that, among other things, finds these files.

There is usually a lost+found directory on every disk partition; /lost+found is the one on the root disk. However, some Unix systems do not create the directory until it is needed.

/mnt

Temporary mount directory: an empty directory conventionally designed for temporarily mounting filesystems.

/opt

Directory tree into which optional software is often installed. On some systems, optional software products are installed instead under /var/opt. On AIX systems, this function is provided by the directory /usr/lpp.

/proc

Process directory, designed to enable processes to be manipulated using Unix file access system calls. Files in this directory correspond to active processes (entries in the kernel process table). On Linux systems, there are also additional files containing various information about the system configuration: interrupt usage, I/O port use, DMA channel allocation, CPU type, and the like. The HP-UX operating system does not use /proc.

/stand

Boot-related files, including the kernel executable. Solaris uses /kernel, and Linux systems use /boot for the same purpose. FreeBSD systems use /stand for installation and system configuration-related programs and use /boot for kernels and related files used for booting.

/tcb

Directory tree for security-related database files on some systems offering enhanced security features, including HP-UX and Tru64 (the name stands for "trusted computing base"). Configuration files related to the TCB are also stored under /etc/auth. /usr/tcb may also be used for this purpose.

/tmp

Temporary directory, available to all users as a scratch directory. The system administrator should see that all the files in this directory are deleted occasionally. Normally, one of the Unix startup scripts will clear /tmp.

/usr

This directory contains subdirectories for locally generated programs, executables for user and administrative commands, shared libraries, and other parts of the Unix operating system. The most important subdirectories of /usr are discussed in more detail in the next section. /usr also sometimes contains application programs.

/var

Spooling and other volatile directories (varying data). Important subdirectories are described below.

2.3.5 The /usr Directory

The directory /usr contains a number of important subdirectories:

/usr/bin

Command binary files and shell scripts. This directory contains public executable programs that are part of the Unix system. Many executables for the X Window System are stored in /usr/bin/X11 or /usr/X11R6/bin.

/usr/include

Include files. This directory contains C-language header files that define the C programmer's interface to standard system features and program libraries. For example, it contains the file stdio.h, which defines the user's interface to the C standard I/O library. The directory /usr/include/sys contains operating system include files.

/usr/lib

Library directory, for public library files. Among other things, this directory contains the standard C libraries for mathematics and I/O. Library files generally have names of the form libx.a or libx.so, where x is one or more characters related to the library's contents; the extensions specify a regular (statically linked) and shared library, respectively.

/usr/local

Local files. By convention, the directory /usr/local/bin holds executable programs that were developed locally or retrieved from the Internet and any sources other than the operating-system vendor. There may be other subdirectories here to hold related files: man (manual pages), lib (libraries), src (source code), doc (documentation), and so on.

/usr/sbin

Administrative commands (except ones required for booting, which are in /sbin).

/usr/share

Shared data. On some recent systems, certain CPU architecture-independent static data files (such as the online manual pages, font directories, the dictionary files for spell, and the like) are stored in subdirectories under /usr/share. The name share reflects the idea that such files could be shared among a group of networked systems, eliminating the need for separate copies on every system.

/usr/share/man

One location for the manual pages directory tree. This directory contains the online version of the Unix reference manuals. It is divided into subdirectories for the various sections of the manual.

Traditionally, the subdirectory structure contains several mann subdirectories holding the raw source for the manual pages in that section and corresponding catn subdirectories storing the formatted versions. On many current systems, however, the latter are eliminated, and manual pages are formatted as needed. In many cases, the source files are stored in compressed form to save even more space.

The significance of the manual sections is described in the Table 2-11.

Table 2-11. Manual-page sections

Contents	BSD style	System V style
User commands	1	1
System calls	2	2
Functions and library routines	3	3
Special files and hardware	4	7
Configuration files and file formats	5	4
Games and demos	6	6 or 1
Miscellaneous: character sets, filesystem types, data type definitions, etc.	7	5
System administration commands	8	1m
Maintenance commands	8	8
Device drivers	4	7 or 9

Among the systems we are considering, the BSD-style organization is used by FreeBSD, Linux, and Tru64, and the System V-style organization is more or less followed by AIX, HP-UX, and Solaris.

/usr/src

Source code for locally built software packages (FreeBSD and Linux). FreeBSD also uses the /usr/ports directory tree for retrieving and building additional software packages.

/usr/ucb

A directory that contains standard Unix commands originally developed under BSD. Recent System V-based systems also provide BSD versions of commands so that users may use the form that they prefer. Some BSD-based versions have similar directories for System V versions of commands, conventionally /usr/5bin. /usr/opt/s5/bin and /usr/opt/s5/sbin perform a similar function under Tru64.

2.3.6 The /var Directory

As we noted, the /var directory tree holds data that changes over time. These are its most important subdirectories:

/var/adm

Administrative directory (home directory of the special adm user). This directory traditionally contains the Unix accounting files although many Unix versions have moved them.

/var/cron, /var/news

/var contains subdirectories used by many system facilities. These examples are used by the cron and Usenet news facilities, respectively.

/var/log

Location for log files maintained by many system facilities.

/var/mail

User mailbox location.

/var/run

Contains files holding the current process IDs of various system daemons and other server and/or execution instance-specific data.

/var/spool

Contains subdirectories for Unix subsystems that provide different kinds of spooling services. Some of the tools using /var/spool subdirectories are the print spooling system, the mail system, and the cron facility.