HDK Technical Reference

Dynamically-loadable kernel modules (DLKM)

Dynamically Loadable Kernel Modules (DLKM) are device drivers and other kernel modules that can be added to a running system without rebooting the system or rebuilding the kernel. All SDI, MDI, and DDI version 8 and later drivers must be written to be DLKMs; other drivers written for DDI versions 4 through 7 can be written as DLKMs or as traditional, statically-loaded drivers. SCO OpenServer 5 does not currently support DLKMs.

DLKMs can be loaded and unloaded on demand or automatically. In either case, DLKM loads the requested module and any other modules on which it depends, based on the information in the ``$depend'' and ``$interface'' fields of the Master(DSP/4dsp) file:

Demand load: Drivers are loaded when a user issues the modadmin command.
All modules listed in the /etc/loadmods file are demand loaded by the idmodload command (run by the init process) when the system is booted. This list can be overridden by the file specified by the modlist argument to idmodload's -f option. If no ``configure'' fields in the driver's System(DSP/4dsp) file are set to Y, the module is not loaded even if it is in the module list.
Auto load: Drivers are loaded when the kernel determines that the functionality provided by a particular module is required to perform some task. For example, the kernel calls DLKM to autoload a loadable device driver on the first open call to any of the driver's configured devices. A loadable STREAMS module is auto loaded on the first I_PUSH of the module.
Demand unload: Drivers are unloaded when the modadmin command is issued, unless the module is being used or another module that is being used depends on it.
Auto unload: A daemon runs periodically to unload any modules that were auto loaded and that are inactive, have not been accessed for a specified amount of time, and on which no other modules have dependencies. For example, an auto loaded device driver becomes a candidate for auto unloading on the last close(D2) of all its configured devices, and an auto loaded STREAMS module becomes a candidate for autounloading on its last I_POP.
The DEF_UNLOAD_DELAY tunable parameter defines the time lapse between when an inactive module becomes a candidate for auto unload. A module can override this time lapse by setting a prefix_UNLOAD_DELAY parameter in its Mtune(DSP/4dsp) file.

Using loadable modules

The process of developing, configuring, and using Dynamically Loadable Kernel Modules consists of several phases:

Register the module with the operating system using the modadmin commands. This is the mechanism that informs the kernel that the loadable module exists and is required before the module can be loaded. For modules other than device drivers, registration establishes a correspondence between a system-wide unique module name and module type-specific data. For device drivers, a correspondence is established between the module name and the driver instance and channel or, for DDI versions prior to version 8, between the module name and the character and block major device numbers. In addition to name registration, the registration process also initializes the autoload mechanism for the drivers.
The module's loadable image is copied from disk into dynamically-allocated kernel memory and he module is link-edited into the kernel.
DLKM relocates the module's symbols and resolves any references the module makes to external symbols.
If the module has a _load(D2) entry point defined, it is called to do any module-specific initialization and setup.
The module is logically connected to the rest of the kernel. For drivers written for DDI versions prior to version 8, DLKM executes special code in the module called ``wrapper'' code that enables the module to initialize itself dynamically. See _load(D2) for more information about wrapper code.

The process of unloading the module involves reversing the steps, and includes disconnecting the module from the kernel and calling the module's _unload(D2) entry point to perform any driver specific cleanup including:

Free all dynamic memory.
Cancel all outstanding calls to timeout(D3), bufcall(D3str), and similar calls.
Disable device interrupts.
Optionally, disable and/or power down the device.

When clean-up is complete, DLKM releases the memory allocated for the module.

Making modules loadable

The following list summarizes the steps required to convert a non-loadable driver to be a loadable driver:

Code _load(D2) and _unload(D2) entry points, which execute when the driver is loaded/unloaded. For drivers that handle interrupts, the _load( ) routine must add the driver's interrupts to the running system, using the cm_intr_attach(D3) function. The _unload( ) routine must disable and remove the driver's interrupts from the running system, using the cm_intr_detach(D3) function. See ``Autoconfiguration''.
For drivers written for DDI versions prior to version 8, code an initialization wrapper as described on the _load(D2) manual page.
Compile the driver.
Create the DSP.
Package and install the driver; see ``Packaging and installing SVR5 drivers''.
Debug the driver; see ``Debugging a DLKM at load time (SVR5 only)''.

Managing loadable modules

This is a summary of commands used to manage loadable modules. For more details, see ``Managing dynamically loadable kernel modules''.

modadmin(1M)

-l: demand load module
-u: demand unload module
-Q module_name: query status
-q module_id: query status
-S: full status of all currently loaded modules
-s: abbreviated status of all currently loaded modules
-d path: modify pathname for driver's loadable image

idtune -c(1M)

Modify tunable parameters and make tuning effective immediately for loadable kernel modules.

User-level programs can use the following system calls to access DLKMs:

getksym(2): get information for global kernel symbol
modload(2): load DLKM
moduload(2): unload DLKM
modpath(2): change DLKM's search path
modstat(2): get status for DLKMs