Device Numbers and Jump Tables

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. 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).

12. 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.

13. 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.

14. 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.

15. 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.

16.

END OF CHAPTER
QUESTIONS???