Specifications

D
evice Driver Programming
16-2
should not be blocked for long periods of time. A device driver that is written for a con-
ventional UNIX kernel can block interrupts for long periods of time without causing prob-
lems. Because a conventional UNIX kernel cannot be preempted while executing in kernel
mode, blocking interrupts is detrimental only to device throughput. Device interrupts can
be blocked for a very long time before throughput is affected.
If device drivers are not multithreaded but are instead dedicated to a processor, the proces-
sor that is specified should not be a shielded processor.
Because you must multithread the device driver to allow multiple users on different
processors to access a device simultaneously, the driver’s critical sections are protected
with spin locks (basic locks and read/write locks), sleep locks, or synchronization vari-
ables. When you use a spin lock, however, you must provide additional protection by rais-
ing the IPL. If a spin lock is locked only at program level, IPL must be raised to prevent a
context switch from occurring. If a context switch were allowed while a spin lock was
held, the hold time on the spin lock would be quite long and could cause other CPUs to
spin for long periods of time while trying to acquire the spin lock. If a spin lock is to be
locked at interrupt level, you must ensure that a process that locks the spin lock at program
level raises the processor IPL to a level that is high enough to block out the interrupt while
the lock is held. Doing so prevents the interrupt-handling routine from spinning forever
while attempting to lock the spin lock that is locked at program level.
Generally, a device driver should need to raise IPL only while a spin lock is held. It might
also need to raise IPL to ensure that a section of code executes without being interrupted,
but such instances are rare.
Whenever possible, use sleep locks. However, these locks cannot be used in interrupt rou-
tines.
It is also important to assign the interrupt(s) generated by the device that is controlled by
the driver to a CPU on which critical, high-priority tasks are not running. You can assign
an interrupt to a particular CPU by modifying the file /etc/conf/mtune.d/pin on
the release system. This file contains the pin to CPU assignments. The changes to the file
do not come into effect until the kernel is rebuilt and the system rebooted.
Device Drivers and VME Bus Errors 16
Applications typically make use of devices that are located on the VME bus. In the event
that any of these VME devices or their corresponding device drivers cause a VME bus
error, the kernel usually panics.
In a simulation or production environment, or even in a development environment where
frequent system reboots are not productive, these kernel panics are not desirable.
As an alternative to kernel panics, the iobus_err(2) system service can be used to
register, catch, and obtain status on VME bus errors, while usually avoiding kernel panics.
(Some VME bus errors are considered non-recoverable by the kernel, and therefore, these
types of VME bus errors still result in kernel panics.)
Typically, whether the VME device of interest has a kernel or user-level device driver, an
application program typically calls iobus_err(2) at system start-up time, usually via a