Module 6: I/O Device Drivers

Introduction

As we learned in the first module, one of the jobs of the operating system is to be a resource manager.
Some resources are going to be pretty much the same, regardless of the operating system — you will
always have a Central Processing Unit (CPU), and you will always have some kind of memory. But aside
from that, the resources or devices an operating system may need to handle may vary pretty significantly,
even within a given base operating system. Most of the operating systems we encounter will have to
handle resources such as:

• output devices
o monitors of some sort
o audio devices (speakers)
• input devices
o keyboards
o mice
o touch screens
o microphones
• input and output devices
o disk drives
▪ hard drives
▪ solid-state drives
▪ CDs
▪ DVDs
▪ USB memory sticks
o Network devices
▪ Network interface cards
▪ Wireless networks

If an operating system isn't designed carefully, integrating these resources as devices in the operating
system can be a mess. Having a uniform way of integrating these devices into the operating system is
important — however, we must still allow flexibility in how we accomplish this, since devices are certainly
not uniform in what they do and how they do it. Taking a look at the table in your text on page 339 (Figure
5-1), you can see some different devices with their typical data rates. The data rates do vary greatly, but
devices vary in more than just their data rates.

Device Configurations

In this module, we need to consider two interfaces — how the device interfaces with the device driver,
and then how the device driver interfaces with the rest of the operating system. Let's look first at how the
device driver interfaces with the device itself.
Device Driver from/to Device

You always need to consider the separation between the peripheral device and the operating system.
The device driver in the operating system must know about what the device does for itself, and in some
cases, how the device does it, and what the operating system needs to do. For example, an early disk
device might simply provide blocks of data from the disk based on a single command from the operating
system. The operating system device driver might need to know how to interact with the driver to
optimally use the disk — to get data from the disk most efficiently and hopefully minimize wear and tear
on the disk. More modern disks might have more capable disk controllers which could take multiple disk
read and write commands and optimize them within the controller. The controller itself may have a
significant memory cache which could reduce actual mechanical activity in the disk. A device driver author
for a disk must know many of these aspects when writing the device driver to use the device properly.

Summarizing from your text, there are several ways a device can interact with a device driver:

• I/O Ports
• Memory Mapped I/O
• Registers
• Interrupts
• Direct Memory Access

Device Driver from/to Operating System

How does the Device Driver interface to the Operating System? As your text says, you should make that
interface as common as possible across all devices. In UNIX-like operating systems, this is accomplished
by establishing a set of functions (or methods, if you like) which are common for all device drivers. Not
coincidentally, these operations are also common to regular files in the operating systems. These
functions are:

• Open — open a device. This call provides a handle to the application, as well as performing
device actions (if any) needed to prepare the device for I/O.
• Close — close a device. This call provides an opportunity for the device to clean up after a
particular use, if necessary.
• Read — read data from a device.
• Write — write data to a device.
• Ioctl — I/O control — this is a catch-all call which allows a device to perform many miscellaneous
and device-specific actions. For example, a streaming tape drive device might have an ioctl call to
rewind the mounted tape, or a DVD device might have an ioctl to eject the DVD.

In UNIX-like operating systems, the device driver is attached to the applications from the file system. As
Tanenbaum states in the text, this makes the user level interface to devices much like the user level
interface to regular files.

One day, this fact was brought home to me when I was working as an administrator in a UNIX lab. The
printer stopped working — students could submit jobs for printing, and the printer software would indicate
that the job completed successfully, but nothing ever came out of the printer. Upon investigating, I noticed
that was something wrong with the device file for the printer (/dev/lp). I looked at it carefully, and it
actually wasn't a device file, but a regular file! Somehow the special device file, /dev/lp, was deleted and
the printer user-level software simply called open("/dev/lp", ...) to open access to the printer, then write()
to send a print job to the printer. Sure enough, when I looked at the content of the regular /dev/lp file, it
just contained the text that was to go to the printer. I simply deleted the file and issued the proper mknod
command using the proper major and minor device numbers (see below), and the printer began to work
as before.

The first video supplied in your course content for this module goes into some detail describing the
interface to the device driver.

In the past, integration of a new device driver into an operating system required the device driver to be
linked into the operating system and a short source file, usually called something like 'conf.c', to be edited.
It was in this file that the developer would decide on what major device number to use, which would
represent the index into an array of structures containing pointers to the entry points of the device driver
(as alluded to in the above presentation). That new 'conf.c' file would also be compiled and linked into the
operating system and then the system would need to be rebooted. After the system reboot, the device
would be installed into the operating system and the only task remaining would be to create the special
device file (either character or block) to serve as the interface to the device driver. That device file would
be created by an administrator using the mknod command:

% mknod /dev/foo c 13 22
% ls -l /dev/foo
crw-r-r-1 root root 13, 22 2015-03-30 14:17 /dev/foo
%

Note again that this command doesn't require a device to be loaded into major device number 13, and if
you try to use it without a device there, you might see this:

% cat /dev/foo
cat: /dev/foo: No such device

Also, note that putting the device file into the /dev directory is purely conventional. You can create device
files anywhere.

However, in just about every modern operating system today (in this case, even including Minix), you can
create, build, and install a new device and device driver without rebooting the system. Minix uses the
'reincarnation' server to this end — that, along with the fact that device drivers can be built within user
space, will make your assignment a bit easier to navigate through (no long build times, and no need to
reboot the system). Linux allows kernel modules, which can include device drivers, to be installed
dynamically, too, using the modprobe command (which can also remove the device driver). When a
Windows device is added, a reboot seems to be usually necessary.

Pseudo-Devices

Some device drivers aren't attached to actual physical peripherals at all. Device drivers are (typically) part
of the kernel, so sometimes a driver might be created as a way to gain information, or to pass information,
into the kernel. It's easy to create a so-called pseudo device driver; just create a device driver that
interfaces to the user as a normal device driver would, but do not include the back end that
communicates with the device. One of the most popular pseudo device drivers is "/dev/null"; a device that
simply immediately returns an end-of-file when it is opened and read and takes whatever is written to it
and throws it into the bit bucket when it is opened and written to. Our project assignment for this module
is a creation of a pseudo device driver to produce an interprocess communication message passing
capability.

Can you find any other pseudo device drivers on UNIX systems? What are they used for?