Driver as part of the kernel

Application programs, executing at the user level, are limited in the ways they can have an adverse impact upon the system. Performance and efficiency considerations are mostly confined to the program itself. An application program can consume excessive disk space, but it cannot raise its own priority level to use excessive amounts of processing time, nor does it have access to sensitive areas of the kernel or other processes.

Drivers can and do have much greater impact on the system. Inefficient driver code can severely degrade overall performance, and driver errors can corrupt or bring down the system. For this reason, testing and debugging driver code is particularly challenging, and must be done carefully. ``Driver testing and debugging'' discusses the facilities available for finding driver errors, as well as some of the special problems that are encountered when testing driver code.

Also, whereas an application program writer is free (within reasonable limits) to declare and use data structures and to use system services, a driver writer is constrained in several ways.

• Kernel functions called by the driver generally do not verify the validity of passed arguments. Therefore, it is the responsibility of the driver developer to check the validity of arguments before passing them to kernel functions.

• Various structure members and device registers must be read or written, and usually some system buffering structure must be used. Many of the functions defined in the Device Driver Interface (DDI) are designed to be used with these structures. These structures are explained in the Section D4 manual pages

• Drivers have no access to standard C library routines; however, the routines included in the DDI and other driver interfaces such as MDI and SDI represent a kind of library and provide some functions similar to those found in the standard C library as well as many functions that are unlike standard C library functions. See the Section D3 manual pages for a complete listing of the DDI driver interface functions.

• Drivers are invoked by the kernel using a set of system tables and the standard C function-calling mechanism. Every member of one of these tables is a structure containing pointers to the driver's entry point routines. The entry point routines make the connection between the calling process and the device driver. The entry points, in turn, call the driver functions to service the caller's requests. See Section D2, ``Driver Entry Point Routines,'' in the manual pages for complete explanations of the driver entry point routines.

• Drivers cannot use floating point arithmetic.