| Previous | Table of Contents | Next |
by Tim Parker
Device drivers provide an interface between the operating system and the peripherals attached to the machine. A typical device driver consists of a number of functions that accept I/O requests from the operating system and instruct the device to perform those requests. In this manner, a uniform interface between devices and the operating system kernel is provided.
We can’t cover everything there is to know about device drivers in a single chapter. Indeed, several sizable books have been written on the subject. Because device drivers are not written by casual users, but mostly by talented programmers, the information supplied here is mainly an introduction to the subject.
The code snippets in this chapter are taken from a set of simple device drivers written in C. They are portable and designed for a UNIX system, but they also execute properly under Linux. Use them only as a guide, if you decide you want to write device drivers. Obtain one of the specialty books on the subject if you get serious about programming device drivers.
Note:
Writing device drivers is, in theory, quite simple. However, the first time you try to write one you’ll be amazed at the number of problems you encounter. Many people consider writing device drivers an art, but all it really takes is practice and experience. There’s a superb sense of satisfaction in writing good device drivers.
Linux uses a device driver for every device attached to the system. The basic device driver instructions are part of the kernel or loaded during the boot process. By using a device driver, the devices appear to the operating system as files that can addressed, redirected, or piped as normal files.
Each device attached to the Linux system is described in a device driver program file, and some parameters about the device are described in a device file, which is usually stored in the /dev directory. When you add a new peripheral to the system, either a device driver must be attached to the Linux operating system to control the device, or you must write or supply a device driver. You also need a device file in the /dev direc-tory for each device. Otherwise, the device can’t be used.
Each device file has an assigned device number that uniquely identifies the device to the operating system. Linux device numbers consist of two parts. The major number identifies which general type the device driver handles, while the minor number can specify a particular unit for that general type of device. For example, multiple hard disk drives will use the same device driver (the same major number), but each has unique minor numbers to identify the specific drives to the operating system.
There are two major types of device drivers: character mode and block mode. Any UNIX device uses one or both of the driver types. Block mode drivers are the most common type. They deal with I/O in blocks of data to and from the kernel’s buffer cache (which copies to memory the data from the cache). Originally designed for use with disk drives, block mode is used with virtually all mass storage devices, such as disk drives, high-capacity tape drives, magneto-optical drives, synchronous modems, and some high-speed printers.
Character mode devices differ from block mode devices in two significant ways. I/O can be processed directly to and from the process’s memory space without using the kernel’s cache. In addition, I/O requests are usually passed directly to the character mode device. Terminals and printers are obvious character mode devices, as are asynchronous modems and some tape drives.
Block mode devices perform a “strategy” function that reads or writes a block of data to the device. A series of special device control functions called ioctl() functions are available with character mode devices. In order to use these ioctl() functions, block mode devices will sometimes use character mode. An example is a tape drive that can use either a character or block mode driver, depending on the type of data being written.
Regardless of the type of device driver, the driver itself performs a series of basic tasks whenever a request is made of the device. First, the device is checked to ensure that it is ready and available for use. If so, it is “opened” to allow the calling process access. Read or write commands are usually executed, and then the device is “closed” to allow other processes access to the device.
| Previous | Table of Contents | Next |