HDK Technical Reference

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''.

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.