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

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