Devices and Drivers (Chapter 7) Khattab Alhabashi

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

• 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 attach open close read reset stop

• select strategy dump psize write timeout

• 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???