You too can understand device numbers and mapping in Solaris
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:
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.












