October 31, 2001, 1:58 PM — Running into someone who understands the
intricacies of Unix device drivers is no longer the awe-inspiring
experience retold from the days of yore. If you were impressed by Unix
gurus who professed to write drivers using cat as a text
editor, it's time to join the real world and enjoy improvements in
kernel configuration, device mapping, and installation that have made
low-level kernel knowledge less of a necessity for the average Unix
system manager. But why dedicate a column to device numbering and
mapping in Solaris?
While installation has become much more automated, troubleshooting
remains a labor-intensive process. What do you do when you add a new
disk drive, and it begins using a device number for which your database isn't
prepared? How do you prevent device numbers from changing across
reboots, and how do you get them to change when you need to remove
hardware or replace failed components? Do you have high-availability
configurations that require identical disk device names on both
machines, even though the SCSI host adaptors are not quite identically
installed and cabled? How do you fix older or third-party applications
with hard-wired device names that fail in the brave new world of
tongue-twisting geographical device names?
This month, we're going to
put you back in charge of the hardware configuration with a tour of
the device identification and numbering process. We'll start with a
look back at how device numbers have been assigned and managed by
Unix, and how the Solaris kernel makes the process much more dynamic
-- and less deterministic at times. We'll dive a bit more deeply into
the depths of device autoconfiguration and numbering under Solaris,
followed by a look at persistence in device numbering and how to
override the defaults and fix some common problems.
Land of 1,000 devices
The late jazz bassist Charles Mingus said that taking something
complex and making it simple showed true creativity. One of the
elegant simplicities of the Unix operating system is the way in which
it presents physical device interfaces to the system programmer.
Devices, such as disk drives, framebuffers, pseudo-terminals, and real
serial ports appear as filesystem entries, allowing the usual set of
file manipulation system calls to be used as the application
programming interface. There's no need to learn a separate device
liturgy for each new type of hardware. Reducing the API suite to a
single set of interfaces makes it easier to port a database, for
example, that may use raw disk devices or a filesystem.
However, the output of ls shows you that device entries
in the filesystem aren't quite identical to those of regular files or
directories:
luey% ls -l sd@3,0:a* brw-r----- 1 root sys 32, 24 Oct 14 12:17 sd@3,0:a crw-r----- 1 root sys 32, 24 Oct 14 12:17 sd@3,0:a,raw
The first character in the mode tells you if this is a character (c)
or block (b) device; character devices are read a byte at a time, like
normal files, while block devices can only be accessed in multiples of
the block size. Disks are the most common block devices, while network
interfaces, terminal devices of all flavors, and tape drives are
character devices. Device, or special files, also sport a pair of
numbers in place of a size; the numbers are the major and minor
identifiers, respectively. Major numbers are indexes into the kernel's
table of device drivers, associating routines to manipulate the device
with the user-visible name for the hardware. Minor numbers are simply
instance numbers for the device -- they tell you how many you have, and
which particular unit of the device family you're addressing. The
difficult problem is telling the kernel about a new device, and making
sure it creates the appropriate associations between filesystem
entries and its own configuration tables.
SunOS 4.x and its Berkeley heritage embedded the problem of device
numbering in the kernel configuration file. If you wanted to add a new
device or increase the largest device minor number in use, you had to
reconfigure and rebuild the kernel. Even simple tasks, such as telling
the kernel that the SCSI disk on target 4 was to be known as sd4
required hand-crafting configuration files and a kernel rebuild. SunOS
devices live in the /dev directory of the root filesystem, a flat
namespace for all device types and instances.
