DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Linking and testing SCO OpenServer 5 drivers

Files needed to link a driver

To be able to link a driver into the kernel, you must create a number of files that define the structure and capabilities of the driver for the link. These files constitute the components of a Driver Software Package (DSP):


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.
Once you have created these files, you can use idinstall to place them in the Link Kit as described in ``Configuring drivers using idinstall(ADM)''.
© 2005 The SCO Group, Inc. All rights reserved.