All critical code sections
in kernel-level drivers
should be protected with appropriate
``Critical code section''
All code sections protected by spin locks
should be as brief as possible
to avoid degrading system performance.
``Spin locks (DDI)'',
``Spin locks (ODDI)'',
Drivers written for
DDI 8, ODDI 5, and later versions
must use the
functions rather than accessing
the lbolt kernel variable.
DDI versions prior to version 8
function with the LBOLT value
rather than accessing lbolt directly.
ODDI drivers prior to version 5
must access lbolt directly.
Note that lbolt can become negative;
for information and guidelines about
using lbolt so that it does not corrupt the kernel.
Use the autoconfiguration facilities
to configure drivers and
to obtain hardware configuration information.
Using these functions reduces driver complexity
and enables the driver to install easily on
a variety of architectures and configurations.
All drivers should be multithreaded.
Single-threaded drivers can severely degrade
system performance when run on multi-processor configurations.
Singlethreaded MDI drivers can use
the MP-aware facility
to reduce the degradation of system performance
when running a single-threaded driver
on a multiprocessor system.
For DDI drivers, see the
and related manual pages;
for ODDI drivers, see the
and related manual pages.
Singlethreaded drivers should be tested
on a multiprocessor system
and multithreaded drivers should be tested
on a uniprocessor system
to ensure that they work properly.
Use the SVR5
function to check privilege;
DDI driver code should never
cr_uid member directly.
SCO OpenServer 5 drivers use the
function to check whether the calling process
has superuser privileges.
Use the DDI
function to get pagesize;
DDI driver code
should not use the NBPP definition.
Drivers should never call the
instead, even within debug-only sections of code.
Drivers should never explicitly panic the system.
Support for the CE_PANIC mode of the
functions will be removed in a future release.
Use the DDI
or the ODDI
function to explicitly call the configured debugger
for driver debugging.
DDI drivers must never access
the ublock for reading or writing.
function to access current values of these parameters.
Any parameters that are not available to
are not valid for driver use.
Driver source code should only #include
the header files listed on the manual pages
for the driver entry points, functions, and structures being used
and general-purpose driver header files
that are discussed in
Because many of these directories are in the
drivers must include the following:
#define _KERNEL /* for UnixWare 7 drivers */
#define _INKERNEL /* for SCO OpenServer drivers */
Driver source and the resulting binary code
must have no external package dependencies
other than the base operating system,
the SCO UDK (UnixWare and OpenServer Development Kit),
the SCO HDK (Hardware Development Kit),
and tools documented on the SCO Hardware Compatibility Homepage.
should not be dependent on any products
other than the base operating system.
When using memory-mapped I/O,
all pointers to memory-mapped addresses
must be declared as volatile.
Drivers that use DMA schemes for I/O
should adhere to the recommendations
about memory allocation in
Do not do direct DMA programming,
but instead use the DDI or ODDI interface
for DMA programming;
Never use BSS memory for DMA-able memory.