Device Management in UNIX
Diwaker Singh
Reg.Id.10808015
B.Tech-MBA (CSE), Lovely Professional University
Punjab
Abstract- This term paper aims to
provide an overview of the concepts of
device management in UNIX
operating system. It deals with the
meaning of the term device
management, how device management
is done in case of UNIX operating
system and various terms and concepts
related with device management in
UNIX operating system.
INTRODUCTION
This term paper deals with the main
heading “Device management in
UNIX” .In this term paper I am
explaining about the basic meaning of
the term device management? The
second part contains the information
about basic terms related to device
management and explanation of
different concepts that are used for
device management in case of UNIX
operating System. It gives a brief idea
of how an operating system interact
with external devices.
I. DEVICE MANAGEMENT?
 WHAT IS IT??
A device driver is a program that
manages the system’s interaction with
a particular type of hardware. The
driver translates between the hardware
commands understood by the device
and the stylized programming interface
used by the kernel. The driver layer
helps keep the kernel reasonably
device independent.
In most cases, device drivers are part
of the kernel; they are not user
processes. However, a driver can be
accessed both from within the kernel
and from user space. User-level access
to devices is usually through special
device files that live in the /dev
directory. The kernel maps operations
on these files into calls to the code of
the driver.
With the remarkable pace at which
new hardware is developed, it is
practically impossible to keep mainline
OS distributions up to date with the
latest hardware. Ergo, you will
occasionally need to add a device
driver to your system to support a new
piece of hardware.
Device drivers are system specific, and
they are often specific to a particular
range of kernel revisions as well.
Drivers for other operating systems
(e.g., Windows) will not work. This
should be kept in mind while
purchasing a new hardware. In
addition, devices vary in their degree
of compatibility and functionality
when used with various Linux
distributions, so it’s wise to pay some
attention to the results other sites have
obtained with any hardware we are
considering.
 EXAMPLE OF DEVICE
DRIVER INTERFACE
 REPRESENTATION OF
DEVICES IN UNIX
All devices are represented by files
called special files that are located in
/dev directory. Thus, device files and
other files are named and accessed in
the same way. A 'regular file' is just an
ordinary data file in the disk. A 'block
special file' represents a device with
characteristics similar to a disk (data
transfer in terms of blocks). A
'character special file' represents a
device with characteristics similar to a
keyboard (data transfer is by stream of
bits in sequential order).
 DEVICE
MANAGEMENT
ORGANISATION
2
 DEVICE FILES
AND DEVICE
NUMBERS
Most devices have a corresponding file
in /dev; network devices are notable
exceptions on modern operating
systems. Complex servers may support
hundreds of devices. Solaris handles
this complexity quite nicely by using a
separate subdirectory of /dev for each
type of device: disk, cd-rom, terminal,
etc.
By virtue of being device files, the
files in /dev each have a major and
minor device number associated with
them. The kernel uses these numbers
to map devicefile references to the
corresponding driver.
The major device number identifies
the driver with which the file is
associated (in other words, the type of
device). The minor device number
usually identifies which particular
instance of a given device type is to be
addressed. The minor device number is
sometimes called the unit number.
You can see the major and minor
number of a device file with ls -l:
linux$ ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Jul 13
01:38 /dev/sda
This example shows the first SCSI
disk on a Linux system. It has a major
number of 8 and a minor number of 0.
The minor device number is
sometimes used by the driver to select
or enable certain characteristics
particular to that device. For example,
a tape drive can have one file in /dev
that rewinds the drive automatically
when it is closed and another file that
does not. The driver is free to interpret
the minor device number in whatever
way it wants. Look up the man page
for the driver to determine what
convention it’s using.
There are actually two primary types
of device files: block device files and
character device files. A block device
is read or written one block (a group of
bytes, usually a multiple of 512) at a
time; a character device can be read or
written one byte at a time. Disks and
tapes lead dual lives; terminals and
printers do not.
Device drivers present a standard
interface to the kernel. Each driver has
routines for performing some or all of
the following functions:
It is sometimes convenient to
implement an abstraction as a device
driver even when it controls no actual
device. Such phantom devices are
known as pseudo-devices. For
example, a user who logs in over the
network is assigned a PTY (pseudo-
TTY) that looks, feels, and smells like
a serial port from the perspective of
high-level software. This trick allows
programs written in the days when
everyone used a terminal to continue
to function in the world of windows
and networks. /dev/zero, /dev/null,
and /dev/random are some other
examples of pseudo-devices.
When a program performs an
operation on a device file, the kernel
intercepts the reference, looks up the
appropriate function name in a table,
and transfers control to the appropriate
3
part of the driver. To perform an
unusual operation that doesn’t have a
direct analog in the filesystem model
(for example, ejecting a floppy disk), a
program can use the ioctl system call
to pass a message directly from user
space into the driver.
 DEVICE FILE CREATION
Device files can be created manually
with the mknod command, with the
syntax
mknod filename type major minor
where filename is the device file to be
created, type is c for a character device
or b for a block device, and major and
minor are the major and minor device
numbers. If you are manually creating
a device file that refers to a driver
that’s already present in your kernel,
check the documentation for the driver
to find the appropriate major and
minor device numbers.
Under Linux, the udev system
dynamically manages the creation and
removal of device files according to
the actual presence (or absence) of
devices. The udevd daemon listens for
messages from the kernel regarding
device status changes.
Based on configuration information in
/etc/udev and /lib/udev, udevd can
take a variety of actions when a device
is discovered or disconnected. By
default, it just creates device files in
/dev.
On Solaris systems, /dev is actually
composed of symbolic links to files in
the /devices directory, which is a
separate filesystem. The Device File
System (devfs) manages the device
files in /devices. These files are
created automatically at boot time by
devfsadmd, which continues to run
after boot to handle update
notifications from the kernel.
Administrators can use devfsadm to
tweak this process, but most
administrators will not need to use it.
The HP-UX kernel creates devices
files at boot time. If new devices are
attached later, administrators must
create the device files manually by
running the mksf, insf, and mknod
commands. The smh tool also
incorporates a limited interface for
viewing device information.
In AIX, the cfgmgr command runs at
boot time to configure devices and to
install drivers for devices that weren’t
formerly present. It prints warnings for
any devices for which the software or
drivers are not installed. Once a device
is detected, AIX remembers it by
placing an identifier in the Object Data
Manager. cfgmgr creates files in /dev
for devices that are successfully
detected and initialized.
Given the existence of these various
tools for automating the creation of
device files, system administrators
running current releases of UNIX and
Linux should never need to manually
manage device files with mknod.
 NAMING CONVENTIONS
FOR DEVICES
Naming conventions for devices are
somewhat random. They are often
holdovers from the way things were
done under UNIX on a DEC PDP-11,
as archaic as that may sound in this
day and age.
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.
4
/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. TTYs are sometimes
represented by more than one device
file; the extra files usually afford
access to alternative flow control
methods or locking protocols.
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 the
tape device is closed. Each vendor has
a different scheme.
The naming conventions for the files
that represent hard disks and SSDs are
rather complex on most systems.
 CUSTOM KERNELS VS
LOADABLE MODULES
When the system is installed, it comes
with a generic kernel that’s designed to
run most applications on most
hardware. The generic kernel includes
many different device drivers and
option packages. Some drivers may
also be dynamically inserted into the
running kernel. On Linux, the udev
system can also manage real-time
device changes, such as the insertion
of a USB device.
There are various schools of thought
on whether production servers should
have custom-built kernels. Although
there is some potential for
performance gains, especially in
embedded systems without much
memory, the manageability trade-off
for patching and system upgrades is
usually a deal breaker. Unless there’s a
legitimate need to wring every last
ounce of performance out of the
system, we recommend using the
vendor’s stock kernel.
When it comes to kernel device [4] www.programmar.com
support, the wise administrator is
usually also the laziest. Use the [5] www.latrobe.edu.au
dynamic module approach whenever
[6] UNIX and Linux System
possible. Avoid building accustom
Administration handbook by Nemeth,
kernel unless it is strictly necessary.
Snyder, Hein and Whaley
On Linux systems, most USB devices
can be attached with no administrator [7] Operating system principles by
intervention. silberchatz and Galvin

CONCLUSION
From the above text we concluded that
UNIX uses device drivers to interact
with the external devices. Every
connected external device has its own
device driver. Device Driver is
software which acts as interface
between the UNIX kernel and the
device. These Device drivers may be
of three types I/P device drivers, O/P
device driver or I/P device driver.

The device manger manages the

interaction between the operating
system and the device. It creates a list
of all the connected device and using
this list it controls the information flow
between operating system and external
device.

ACKNOWLEDGMENT
I Diwaker Singh Student of B. Tech.-
MBA (CSE) would like to thank my
teacher for the corresponding subject
that is Ms. Neha Bhateja for her
guidance during the preparation of this
term paper. This term paper has surely
enhanced my knowledge. I would also
like to thank my friends who helped
me in gathering information about the
topic.

REFERENCES
[1]www.wikipedia.com

[2] www.answers.com

[3] www.cs.utsa.edu