Specifications

Developing a Device Drive
r
10-23
device driver uses a local routine to probe each VME slot until the device is found. It
ignores slots that are already marked as configured. When it finds the HSA controller in a
slot, it fills the associated adapter array entry with the slot and bus address
Error Handling 10
A device driver should be coded to handle all sorts of error possibilities, including invalid
arguments and data passed from a user to a malfunctioning hardware device. A good
device driver handles these situations cleanly without causing the system to panic or halt.
There are many different types of I/O errors.
Some I/O errors are related to defensive programming techniques, such as testing for
non-NULL pointers before using them, validating passed parameters on the argument
list—for example, the minor number of the device. Another type of I/O error is related to
the semantics of the I/O access. For example, a driver can check that a non-sharable device
(such as a printer) is not opened multiple times.
It is strongly recommended that you become familiar with the technical reference manual
of the device controller to which you are interfacing. This is necessary to find the various
hardware error reporting facilities supported by the device controller, such as status regis-
ters, special interrupts, and so on. Typically, drivers are responsible for monitoring and
handling all device controller errors.
The driver carries out monitoring and handling functions depending on the means of com-
munication between the device and the rest of the system. When using programmed I/O,
the driver is responsible for polling the status of the devices to check for errors. Failed I/O
commands must be retried if desirable. Drivers must log significant errors to an error log.
This can be done using the cmn_err(D3) kernel support routine.When necessary, driv-
ers must return error codes to the user. When using DMAs or interrupt-based I/O, the
driver is responsible for checking the source of the interrupt in the interrupt handler each
time an interrupt is received. It is also responsible for checking for missed or absent or
dropped interrupts by programming for the unexpected and using timeouts.
The mechanism for reporting errors is the value reported to the calling process from the
driver’s routine. This is the error numbers, such as ENXIO. It can also be cmn_err(D3 ) ,
which prints a message to either the system console or the circular buffer putbuf. The
putbuf buffer is read by the crash(1M) utility.
cmn_err() classifies the error condition according to its severity level. You can specify
three severity levels as follows. CE_NOTE is used to report system events that do not nec-
essarily require action, but might interest the system administrator. For example, it can be
used to report the status of control lines on an RS-232C interface for a serial driver.
CE_WARN is used to report events that require immediate attention—for example, those
that might cause the system to panic if an action is not taken. For example, this level must
be used when a device does not initialize properly, a buffer cannot be allocated during ini-
tialization, or the maximum number of devices supported has been reached. CE_PANIC is
used only for debugging or in the case of severe errors that indicate that the system cannot
continue to function. This level halts processing. For example, this level must be used
when the memory for essential resources such as locks cannot be allocated or when unex-
pected commands sizes or queue length are found. Finally, CE_CONT is used to continue a
previous message or display an informative message not connected with an error. In addi-
tion, printf() can be used to generate error messages sent to the system console.