DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
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.

See also:

All DDI 8 kernel drivers and modules must be implemented as DLKMs. They should be coded so they also work as statically-linked drivers.

Using loadable modules

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

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

  2. The module's loadable image is copied from disk into dynamically-allocated kernel memory and he module is link-edited into the kernel.

  3. DLKM relocates the module's symbols and resolves any references the module makes to external symbols.

  4. If the module has a _load(D2) entry point defined, it is called to do any module-specific initialization and setup.

  5. 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:

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:

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

© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005