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
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.
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
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.
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005