Specifications

evice Driver Programming

2-4

much more slowly than the CPU, the data transfer can squander many processor cycles if

the CPU waits on the drive. To avoid this, the driver normally suspends execution of the

process until the transfer completes, freeing the CPU to service other processes. When the

data transfer completes, the device sends an interrupt telling the original process to resume

execution.

The processing needed to handle hardware interrupts is another of the major differences

between drivers and application programs.

Driver As Part of the Kernel 2

Applications, running at the user level, cannot severely impair the system. Performance

and efﬁciency considerations mostly affect them in their own address space. Applications

can use excessive disk space, but can neither raise their own priority level to use excessive

amounts of processing time nor access either sensitive areas of the kernel or other pro-

cesses.

But drivers can and do affect the kernel. Inefﬁcient driver code can severely degrade over-

all performance, and driver errors can corrupt or crash the system. For these reasons, test-

ing and debugging driver code is particularly challenging, and requires great care.

Chapter 15 discusses both the tools for finding driver errors and the special problems in

testing driver code.

Also, while application programmers can freely (within reasonable limits) declare and use

data structures and system services, driver programmers face many constraints:

• Many kernel functions called by the driver do not validate passed argu-

ments. Therefore, drivers must validate arguments before passing them to

kernel functions.

• Drivers must include numerous header ﬁles declaring data types, initializ-

ing constants, and defining system structures. The exact list of header files

varies from driver to driver; one of the following sections in this chapter

describes the most commonly-used header ﬁles.

• Drivers read from and write to various structure members and device regis-

ters, and often use a system buffering structure. The UNIX system Device

Driver Interface/Driver-Kernel Interface (DDI/DKI) defines many func-

tions for use with drivers. Section D4 of the on-line Device Driver Ref-

erence explains the structures.

• Drivers cannot access standard C library routines; however, the routines

included in the DDI/DKI represent a kind of library and provide some

functions like those in the standard C library. The DDI/DKI also provides

many functions unlike standard C library functions. See Section D3 of the

on-line Device Driver Reference for complete explanations of the driver

interface routines.