DSP (Driver Software Package)
A Driver Software Package (DSP) is a set of object,
configuration, and script files used
to install and configure an add-on driver.
A DSP for a device driver
typically consists of the following components.
Some are required, others are optional.
The driver's DSP includes all these files
in the driver's source directory.
The
idinstall
command installs these into the appropriate place
in the link kit,
usually in the /etc/conf tree,
unless an alternate location has been set up.
The pathname shown in parentheses in this list
is the location of the file after
idinstall
is run for the driver.
The term name refers to a file or directory
that takes its name from the name of the driver being installed.
For example, when installing the Adaptec host bus
adapter driver, the module name is adsc,
so idinstall puts the Driver.o file
into the pack.d/adsc/Driver.o file
and the
Master(DSP/4dsp)
file into the mdevice.d/adsc file.
SVR5 DSP files
Driver.o (pack.d/name/Driver.o)-
Required.
Driver object file to be linked into kernel.
Master(4dsp) (mdevice.d/name)-
Required.
Describes general driver characteristics
including the
driver interface versions
used in the driver,
driver dependencies for
dynamically loadable kernel modules,
and a unique character string
that will be used in error message text
generated by this driver.
System(4dsp) (sdevice.d/name)-
Required.
System-specific driver configuration data
required to link the driver into the kernel.
For drivers that use DDI versions prior to version 8,
specify the L characteristic
for a dynamically loadable kernel module.
For drivers that use DDI 8 and later,
specify the S characteristic
for drivers that must be statically loaded
at system initialization,
such as HBA drivers that are required to boot the system.
Node(4dsp) (node.d/name)-
Required for DDI 8 drivers;
optional for others.
/dev special device node data.
Drvmap(4dsp) (drvmap.d/name)-
Required for autoconfigured drivers;
optional for others.
Hardware description data
used by the
autoconfiguration system.
Space.c(4dsp) (pack.d/name/space.c)-
Optional.
Driver data structure allocations and initializations.
MDI drivers define most customizable parameters
through the
bcfg(DSP/4dsp)
file rather than a Space.c file.
bcfg(4dsp)-
Required for MDI drivers.
Defines the DSP and the hardware parameters
for the driver and device.
Ftab(4dsp) (ftab.d/name)-
Optional.
Functional table specifications.
Init(4dsp) (init.d/name)-
Optional.
inittab(4)
entry data.
Not used for MDI drivers.
$LOCALE/msg.o -
Optional.
Localized copies of message files for
$LOCALE.
Mtune(4dsp) (mtune.d/name-
Optional.
Tunable parameter definitions.
Each entry specifies the default, minimum, and maximum values.
dynamically loadable drivers
can specify a prefix_UNLOAD_DELAY parameter
that overrides the value of
the global auto-unload delay parameter.
MDI drivers that define tunable parameters
in their Mtune files
should define a CUSTOM variable in their
bcfg(DSP/4dsp)
file for each tunable value that is declared.
Autotune(4dsp) (autotune.d/name)-
Optional.
Autotuning parmeter definitions.
This is useful for preallocation of buffers
based on increased memory usage.
Rc (rc.d.d/name)-
Optional.
System startup script for the driver.
Sd (mdevice.d/name)/Sd-
Optional.
System shutdown script for the driver.
Stubs.c(4dsp) (pack.d/name/Stubs.c)-
Optional.
Stubs for symbols defined in a driver
that will not be installed.
Modstub.o (pack.d/name/Modstub.o)-
Optional.
Stub object file for statically-linked modules.
This is used when performing a normal
idbuild to build a new kernel,
but skipped over when building
a DLKM with the idbuild -M command.
The Modstub.o file should contain symbols
that are necessary for a statically linked version of the driver
but not used for the driver as a DLKM.
This file is not used for any DDI 8 drivers
or MDI drivers even when written for DDI version 7,
because these drivers must all be dynamically loadable.
SCO OpenServer 5 DSP files
Driver.o-
A COFF object module containing the compiled driver code.
Master-
An entry to be inserted in
mdevice(F)
to define the capabilities of the driver.
An example Master file entry might look like this:
xnamex Iocrwi iHc xx 0 0 1 1 1
The first field (``xnamex'') is the internal name of the driver
consisting of up to 8 characters. The second field (``Iocrwi'')
indicates that the driver has init, open,
close, read, write, and ioctl
routines. The third field (``iHc'') specifies that the driver is
installable, controls actual hardware,
and is a character driver. The fourth field (``xx'') is the prefix
of the driver routines. The prefix can be up to 5 characters long
and, although it does not have to be the same as the device name field, it
helps minimize confusion if they are the same. The fifth and sixth fields
(block and character major device numbers) are 0
and will be filled in automatically. The seventh and eighth fields are
the minimum and maximum numbers of device units. The
ninth field indicates the DMA channel that will be used.
System-
An entry to be inserted in
sdevice(F)
to define hardware parameters for the device to be controlled.
An example System file entry might look like this:
xnamex Y 1 5 1 1 338 341 0 0
The first field (``xnamex'') must be the same as the first field in the
Master file. The second field (``Y'') indicates that the
driver is to be linked into the kernel. The third field usually indicates
the number of units connected to the controller. The fourth field
(``5'') is the interrupt priority level (IPL); the
CPU software priority level at which interrupts will
be processed. The ``1'' in the fifth field indicates that the driver
needs exclusive use of the interrupt request line (IRQ) specified
in the sixth field. In this example, the controller uses interrupt 1.
The seventh and eighth
fields are the start and end I/O addresses. In this
example, the device does not respond to dual-ported RAM
addresses, so the ninth and tenth fields are set to ``0''.
See also
``Dynamic interrupt registration by BTLDs''.
You may also need to supply the following files:
Mtune-
Entries to be inserted in
mtune(F)
to define new values for tunable kernel parameters.
Space.c-
A C source file that can be edited to adjust the configuration
of the driver.
Stubs.c-
A C source file that provides function stubs if the
driver is not linked into the kernel. It is only needed if the
driver is referenced by other drivers.
.h-
Header files included by Space.c.
To allow device nodes and
inittab(F)
entries to be configured in the kernel environment after the kernel has
been relinked, the following files may also be specified:
Node-
Definitions of device files to be created in the /dev
hierarchy to support operation of the driver.
The format of this file is described on the
idmknod(ADM)
manual page.
Init-
Entries to be inserted in
/etc/inittab.
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005