Transcript Devices and Drivers (Chapter 7)

Devices and Drivers (Chapter 7)
Khattab Alhabashi
UNIX System Administration
Introduction

Definition: A device driver is a program that manages the system’s interaction
with a particular piece of hardware.

The driver translates between the hardware commands understood by the
device and the stylized programming interface used by the kernel.

The existence of the driver layer helps to keep UNIX reasonably deviceindependent.

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 provided through special device file that live in
the /dev directory.
Introduction Contd.

Most devices in the system will fall into three categories:
1) SCSI:
– Devices that attach to a SCSI bus are easy to configure.
– Most systems have one driver that allows direct access to the SCSI bus,
plus additional drivers for special types of devices such as disks and tapes.
2) Vendor:
– Most devices you can buy from your hardware vendor will already be
supported by the operating system.
– Unless you have explicitly removed drivers, the kernel will usually recognize
a new device as soon as you install it.
– The appropriate device files in /dev will already have been created for you,
or the OS will create them on the fly.
Introduction Contd.
3) Third-party:
– When you purchase a piece of hardware from a third party (someone other
than your hardware vendor), it will usually come with an installation script
that installs the device, configures the kernel if necessary, and makes
devices entries.
– On systems with loadable drivers, kernel configuration may not be
necessary.
Device Numbers and Jump Tables

Device files are mapped to devices via their “major and minor device numbers”,
values that are stored in the file’s inode structure.

The major device number identifies the driver that the file is associated with.

The minor device number identifies which particular device of a given type is to
be addressed. It is often called the unit number or “instance” of the device.

There are two types of device files:
– Block device files: it is read or written a block (a group of bytes, usually
multiple of 512) at a time.
– Character device files: it can be read or written one byte at a time.
Device Numbers and Jump Tables Contd.

Some devices support access via both block and character device files.

Each driver has routines for performing some or all of the following functions:
probe
select
attach
strategy
open
dump
close
psize
read
write
reset
timeout
stop
process a transmit interrupt
process a receive interrupt
ioctl (input / output control)

Inside the kernel, the addresses of these functions for each driver are stored in
a structure called a jump table.
Device Numbers and Jump Tables Contd.

There are actually two tables:
- One for character device and
- One for block devices.

The jump tables are indexed by major device numbers.

When a program performs an operation on a device file, the kernel automatically
catches the reference, looks up the appropriate function name in the jump table,
and transfers control to it.

To perform an unusual operation that doesn’t have a direct analog in filesystem
model (for example, ejecting floppy disk), the ioctl system call is used to pass a
message directly from user space into the driver.
Device Numbers and Jump Tables Contd.

Three examples were discussed in this chapter about adding device drivers:
- Adding a BSD Device Driver: Adding a completely new device driver to BSD
machine involves adding it to a couple of configuration files and editing the
kernel source code to include references to the driver’s routine.
- Adding an HP-UX Device Driver: On HP-UX systems, the jump tables are
constructed from specifications in a text file called master.
- Adding an IRIX Device Driver: IRIX uses a directory of files
(/var/sysgen/master.d) to perform the same function as the single master file in
HP-UX.
Device Numbers and Jump Tables Contd.

There are some common steps in all three examples that have to be done after
adding and modifying the files specified for each example:
- Building a new kernel.
- Copying the old kernel aside and installing the new kernel.
- Rebooting and testing the new kernel.
- Creating device files and test the device itself.
Device Files

By convention, device files are kept in the /dev directory.

ATT systems handle device files quite nicely by using separate subdirectory of
/dev for each type of device:
disk, tape, terminal, etc.

Device files are created with the mknod command, which has 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.
- major and minor are the major and minor device numbers.
Device Files Contd.

A shell script called MAKEDEV is sometimes provided (in /dev) to automatically
supply default values to mknod.

You need to scan through the script to find the arguments needed for your
device. For example, to make PTY entries on a SunOS system, you would use
the following command:
# cd /dev
# ./MAKEDEV pty
Naming Conventions For Devices

Devices that have both block and character identities usually
- preface the character device name with the letter r for “row”
(e.g., /dev/sd0 and /dev/rsd0), or
- place it in a subdirectory with a name that starts with r
(e.g., /dev/dsk/dks0d3s0 vs. /dev/rdsk/dks0d3s0).

Serial devices are usually named tty followed by a sequence of letters that
identify the interface the port is attached to (See chapter 8 for more information
about serial ports).
Naming Conventions For Devices Contd.

BSD disk names often begin with a two-letter abbreviation for either the drive of
the controller, followed by the drive number and partition name.
- Example: sd0a is the block device representing the partition of the first disk
drive on a SCSI controller; rsd0a is the corresponding character device.

The names of tapes and devices often include not only a reference to the drive
itself, but also an indication of whether the device rewinds after each tape
operation and the density at which it reads and writes.
Loadable Kernel Modules

Loadable modules allow device drivers to be linked into and removed from the
kernel while it is running.
- This makes the installation of drivers much easier, since the kernel binary does
not have to be changed.
- It also allows the kernel to be smaller, because drivers are not loaded unless
they are needed.

Loadable modules are implemented by providing one or more documents
“hooks” into the kernel where additional device drivers can grab on.

A user-level command communicates with the kernel and tells it to load new
modules into memory and to make entries for them in the system’s jump tables.
Loadable kernel Modules Contd.

Although loadable drivers are convenient, they are not entirely safe.

Any time you load or unload a module, you risk causing a kernel panic.

Like other aspects of device and driver management, the implementation of
loadable modules is operating system dependent.

There are four of the example systems that support loadable modules:
- Solaris: In Solaris, virtually everything is a loadable module. The modinfo
command lists the currently-loaded modules. You can add a driver with the
add_drv command.
Loadable Kernel Modules Contd.
- HP-UX: Generic HP-UX does not support loadable modules, but there is an
option that allows the loading of STREAMS modules.
- IRIX: IRIX 5.2 supports loadable modules; earlier versions did not. Modules
are manipulated with the ml command. ml with the list option catalogs the
modules that the kernel is currently aware of.
- SunOS: SunOS versions 4.1.2 and later contain support for loadable modules.
Currently-loaded modules can be listed with modstat.
END OF CHAPTER
QUESTIONS???