Dynamically Loadable Kernel Modules (DLKM)

An advanced operating system feature called Dynamically Loadable Kernel Modules (DLKM) provides the infrastructure necessary to load different subsystems into a running kernel. DLKM also provides the mechanisms to unload, configure, and query loaded subsystems.

The current HP-UX kernel configuration mechanism has been extended to support the configuration of DLKM. This introduces new commands, extends existing commands and adds files and directories to the current HP-UX directory structure.

With the introduction of DLKM, the system now contains both the static kernel and a set of loaded modules, each of which contains separate symbol tables and unwind information. Commands, libraries, and any applications which interact with kernel data, symbols, etc., must now also address loadable modules in order to view the entire system.

User level interfaces into the kernel have been modified to be made "DLKM-aware" in order to obtain information from both the static kernel and any modules that have been loaded.

Additional commands and system calls have been added to load, unload, configure, and query for loadable modules.

The primary user level interface changes are as follows:

New system calls: getksym(2), modadm(2), modload(2), moduload(2), modpath(2), modstat(2).
The getksym(2) system call obtains global kernel symbol information.
The modadm(2) system call provides administrative access to DLKM modules.
The modload(2) system call loads a loadable kernel module.
The moduload(2) system call unloads kernel modules.
The modpath(2) system call changes the search path for loadable modules.
The modstat(2) system call obtains information about loadable modules.
Modified system call: ioctl(2)
The ioctl(2) will be extended to include the following:
MIOC_READKSYM - Read buflen bytes of kernel memory starting at the address for the symbol name.
MIOC_WRITEKSYM - Write buflen bytes into kernel memory starting at the address for the symbol name.
MIOC_IREADKSYM - Indirect read: Read sizeof(void *)bytes of kernel memory starting at the address for the symbol name. Use that address to read buflen bytes of the kernel memory.
MIOC_IWRITEKSYM - Indirect write: read sizeof(void *) bytes of kernel memory starting at the address for the symbol name. Use that as the kernel memory address into which buflen bytes from buf are written.
MIOC_LOCKSYM - Increase by one the hold count on the module whose name is given as the third argument to ioctl, thereby preventing the module from being unloaded.
MIOC_UNLOCKSYM - Decrease by one the hold count on the module whose name is given as the third argument to ioctl, thereby making the module a candidate for unloading if the hold count is now 0.

Kernel Configuration

The change in the kernel configuration design for DLKM revolves around the introduction of modules. A module may be viewed as an atomic unit that may be installed or removed from the system, to be configured and built as desired.

The following information presents primary kernel configuration features visible to users.

New User Level Commands

kmadmin(1M)

kmadmin(1M) is an administrative command for dynamically loadable kernel modules allowing administrators to load, unload, and query for loadable modules.

kminstall(1M)

kminstall(1M) installs, removes or updates a module on a system.

kmsystem(1M)

kmsystem(1M) provides an interface to set the flags indicating whether a module needs to be configured and whether it needs to be built as loadable or static.

kmtune(1M)

kmtune(1M) provides an interface to set the tunable parameters for a module.

kmmodreg(1M)

kmmodreg(1M) registers or unregisters a loadable module with the kernel.

kmupdate(1M)

kmupdate(1M) updates default kernel file and associated modules and context files or updates specified loadable modules.

Modified User Level Commands

config(1M)

config(1M) currently is used to build the static kernel. New options are added to this command to allow the build of loadable modules. It will be possible to build the specified loadable modules individually and dynamically, without requiring a rebuild or reboot of the entire system.

Old Usage:

/usr/sbin/config [-t] [-m master] [-c c_file] [-l m_file] [-r dir] [-s] systemfile

New Usage:

/usr/sbin/config [-S] [-#] [-t] [-m master] [-c c_file] [-l m_file] [-r dir] [-u] [-s] systemfile

-S option will build all modules statically.

-u updates kernel file and associated modules and context files during next shutdown.

-# option will be the debug option.

/usr/sbin/config -M module [[-M mod-name]...] [-m master] [-u] [-#]

-M option will build specified loadable modules

-u updates the module.

-# option will be the debug option.

mk_kernel(1M)

mk_kernel(1M) currently calls config(1M) to build the static kernel. New options to build loadable modules are added to this command. It will call config(1M) with the extended options accordingly.

Old Usage:

/usr/sbin/mk_kernel [-v] [-o <target file] [-s <system file>]

New usage:

/usr/sbin/mk_kernel[[-M mod-name]..][-v][-o <target file][-s <system file]

-M option will build specified loadable modules

New Files and Directories

New Directories

/usr/conf/interface.d

/usr/conf/km.d

/usr/conf/km.d/<mod-name>

/stand/build/dlkm.vmunix_test

/stand/build/dlkm.vmunix_test/mod.d

/stand/build/dlkm.vmunix_test/node.d

/stand/build/dlkm.vmunix_test/system.d

/stand/build/km.d

/stand/build/km.d/<mod-name>

/stand/build/mod_wk.d

/stand/dlkm

/stand/dlkm/mod.d

/stand/dlkm/node.d

/stand/dlkm/system.d

/stand/dlkm.vmunix.prev

/stand/dlkm.vmunix.prev/mod.d

/stand/dlkm.vmunix.prev/node.d

/stand/dlkm.vmunix.prev/system.d

/stand/system.d

New Files

/usr/conf/gen/config.lm

/usr/conf/interface.d/<name.<ver>>

/usr/conf/master.d/<mod-name>

/usr/conf/km.d/<mod-name>/space.h

/usr/conf/km.d/<mod-name>/mod.o

/usr/conf/km.d/<mod-name>/Modstub.o

/stand/build/dlkm.vmunix_test/mod_register

/stand/build/dlkm.vmunix_test/mod.d/<mod-name>

/stand/build/dlkm.vmunix_test/node.d/<mod-name>

/stand/build/dlkm.vmunix_test/system

/stand/build/dlkm.vmunix_test/system.d/<mod-name>

/stand/build/km.d/<mod-name>/mod_reg

/stand/build/mod_wk.d/<mod-name>

/stand/dlkm/mod_register

/stand/dlkm/mod.d/<mod-name>

/stand/dlkm/node.d/<mod-name>

/stand/dlkm/system

/stand/dlkm/system.d/<mod-name>

/stand/build/tune.h

/stand/build/config.mod

/stand/system.d/<mod-name>

Modified Master File

The format of the master file has been extended to include the following additional sections:

$LOADABLE section - indicates whether module is capable of being loaded.

$VERSION section - indicates version number.

$INTERFACE section - indicates the interfaces on which the module depends.

$TYPE section - indicates the type of a module and type specific information.

All the currently existing sections will still be maintained.

Additional Details

With the introduction of DLKM, commands, libraries, and tools accessing kernel information will need to be modified to access loadable module information in addition to the static kernel. This includes, but is not limited to, kernel debuggers, profiling tools, system administration facilities, system installation, and kernel dump utilities.

Prior to 11.0, there was only one system file, /stand/system. With the introduction of DLKM, every modulenow has its own system file.

The /stand/system file still exists for current subsystems. A user or program should use kmsystem(1M) and kmtune(1M) to edit the /stand/system file and individual system files for modules. kmsystem(1M) is used to specify whether a module needs to be configured or unconfigured. kmsystem(1M) is also used to specify whether a loadable module needs to be configured as loadable or static. The kmtune(1M) command is used to set, retrieve, query, or increment tunable parameters for a module.

The kernel is no longer a single executable (/stand/vmunix). It rather consists of a collection of static kernel files in memory, the kernel symbol table file, and the loadable images of dynamic modules. The user may may build the complete new kernel the same way as before. Since the kernel is no longer a single file, moving /stand/build/vmunix_test to /stand/vmunix and rebooting will no longer be sufficient.

The user will need to execute a new command, kmupdate(1M), that initiates the move of the specified kernel file together with its associated directory containing related files during the next shutdown. Instead of rebooting, the user will need to execute the shutdown command.

Programs using mk_kernel(1M) or config(1M) will need to be compiled with the new options in order to take full advantage of the DLKM feature.

The DLKM feature provides the ability to add kernel subsystems on an as needed basis. Modules can be loaded on demand (via the kmadmin(1M) command) or automatically when the functionality contained within the modules has been accessed. This capability enables the system to operate with a static kernel providing the capability to add functionality as needed without rebuilding/rebooting the entire kernel. The impact on the system when a module is first loaded is expected to be negligible.

With the DLKM feature, it will no longer be necessary to relink the entire kernel and reboot the system in order to include a loadable module. The kernel configuration extension will allow loadable modules to be built individually and dynamically as required. This will reduce the number of kernel rebuilds and system downtime, thereby enhancing the overall performance of kernel configuration.

DLKM not only provides the ability to build dynamic modules but also to build loadable modules as static modules which enables administrators to include the module's functionality in the static kernel.