A driver should not attempt to access
any devices other than those controlled by the driver itself.
Drivers must never attempt to program the
PIC (Programmable Interrupt Controller)
or PIT (Programmable Interval Timer)
to avoid conflicts with other drivers
or handle hardware conflicts
such as the lack of an Intel 8259 in the configured hardware.
If the driver needs to delay execution
for a small, fixed period of time,
it should call
DDI drivers should use
if the driver needs to spin on some hardware condition
such as the outcome of a status register
for less than 1/100th of a second.
This provides a fixed,
bounded spin without using
#define SPIN_IN_MICROSECS 10000 /* .01 seconds */
ODDI drivers should use the
function in this case.
<driver writes to memory-mapped register or calls outb(D3), etc.>
/* give register/device time to catch up */
<check register or continue with multipart programming of device>
If the driver needs to busy-spin a longer period,
use a timeout (see
or release processor control and block.
Delays and busy-waits can increase the preemption latency
that is experienced by high-priority processes.
This is especially important in a realtime environment,
where short and bounded preemption latency
can be critical.
Drivers should never program or access information
about the bus except with the autoconfiguration and autodetection
mechanisms discussed in
Most peripheral devices are intelligent,
meaning that they contain their own microprocessor
that can hold driver code.
Proper use of firmware can enhance
the features, portability, and performance
of your device.
Drivers should take full advantage of the board's intelligence
by writing firmware code
or code that is downloaded
to controller RAM at system boot time.
Board diagnostics are often handled this way.
You may also want to include a basic subset
of the protocol necessary to talk
to the host processor directly,
such as the memory management protocol,
Drivers can download code to an adapter in a variety of ways.
If the code is relatively small (less than a page),
locate the code within the driver data itself
and avoid the complexity of a user-level process
that downloads the microcode.
If the code is large,
provide a simple download program and the required
Drivers that use MDI 2 and later versions
can use the
and, for MDI 2.1 and later,
to download code to the adapter.
MDI version 2 drivers can use the
functions to download code to the hardware.
MDI version 2.1 adds the
function that allows larger amounts of data to be downloaded.
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005