Page 383 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes Drivers must be configurable, which means not having any built-in assumptions about which
interrupt lines or I/O ports certain devices use. For example, the printer port on the IBM PC
and its successors has been at address 0x378 for more than 20 years and it is unlikely to change
now. But a printer driver that has this address hard coded into it is not conformant.

Being multiprocessor safe is also a requirement as Windows 2000 was designed for use on
multiprocessors. Concretely, this requirement means while a driver is actively running and
processing one request on behalf of one CPU, a second request may come in on behalf of a
different CPU. The second CPU may begin executing the driver code simultaneously with the
first one. The driver must function correctly even when being executed concurrently by two or
more CPUs, which implies that all sensitive data structures may only be accessed from inside
critical regions. Just assuming that there will not be any other calls until the current one is
finished is not permitted.

Finally, conformant drivers must work not only on Windows 2000 but also on Windows 98. It
may be necessary to recompile the driver on each system however, and use of C preprocessor
commands to isolate platform dependencies is permitted.

In UNIX, drivers are located by using their major device numbers. Windows 2000 uses a different
scheme. At boot time, or when a new hot pluggable plug-and-play device is attached to the
computer, Windows 2000 automatically detects it and calls the plug-and-play manager. The
manager queries the device to find out what the manufacturer and model number are. Equipped
with this knowledge, it looks on the hard disk in a certain directory to see if it has the driver.
If it does not, it displays a dialog box asking the user to insert a floppy disk or CD-ROM with
the driver. Once the driver is located, it is loaded into memory.

Each driver must supply a set of procedures that can be called to get its services. The first one,
called DriverEntry, initializes the driver. It is called just after the driver is loaded. It may create
tables and data structures, but must not touch the device yet. It also fills in some of the fields
of the driver object created by the I/O manager when the driver was loaded. The fields in the
driver object include pointers to all the other procedures that drivers must supply. In addition,
for each device controlled by the driver (e.g., each IDE disk controlled by the IDE disk driver),
a device object is created and initialized to point to the driver object. These driver objects are
entered into a special directory,\??. Given a device object, the driver object can be located easily,
and hence its methods can be called.

A second required procedure is AddDevice, which is called once (by the plug-and-play manager)
for each device to be added. Once this has been accomplished, the driver is called with the first
IRP, which sets up the interrupt vector and actually initializes the hardware. Other procedures that
drivers must contain are the interrupt service procedure, various timer management procedures,
a fast I/O path, DMA control, a way to cancel currently executing requests, and many more. All
in all, Windows 2000 drivers are so complex that multiple sites have been written about them.

A driver in Windows 2000 may do all the work by itself, as the printer driver does in Figure
13.2 (just as an example). On the other hand, drivers may also be stacked, which means that
a request may pass through a sequence of drivers, each doing part of the work. Two stacked
drivers are also illustrated in Figure 13.2.

376 LOVELY PROFESSIONAL UNIVERSITY