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