Managing and Developing Dynamically Loadable Kernel Modules

Developing Dynamically Loadable Kernel Modules

Chapter 12538

Modstub.o File Deﬁnition

An optional component, the Modstub.o ﬁle is statically conﬁgured into

the kernel as a “place holder” for functions implemented in a loadable

module that will be loaded at a later time. Its purpose is to enable the

kernel to resolve references to the absent module’s functions.

Modstub.o contains “stubs” for entry points deﬁned in the associated

loadable module that can be referenced by other statically linked kernel

modules currently conﬁgured in the system. Access to a stub causes the

kernel to auto load the associated loadable module.

Conﬁguring a module that uses stubs requires a full kernel build so that

the stubs can be statically linked to the kernel.

Initializing and Terminating DLKM Modules

In a traditional system with statically linked modules, the modules are

initialized during system boot. Because dynamically loadable modules

can be loaded either during boot or after the system is booted, they must

be initialized differently than modules that are statically linked into the

kernel during system boot. For HP-UX 11i Version 1.5 systems, loadable

kernel modules can be conﬁgured to be loaded during the early stages of

system boot. On PA systems, dynamically loadable modules must be

loaded at run time. Boot time loading on PA platforms will be available

in a future HP-UX release.

The rest of this section describes the steps that each type of dynamically

loadable module must take to initialize itself and to terminate itself. In

addition to WSIO class drivers, WSIO interface drivers, STREAMS

drivers, STREAMS modules, and miscellaneous modules, this section

includes the initialization and termination tasks for WSIO monolithic

drivers. A monolithic driver is both a class driver (one that has a device

special ﬁle) and an interface driver (one that touches real hardware and

registers).

WSIO Class Drivers

To make a WSIO class driver loadable, the driver must provide a

_load() and _unload() function and make minor changes to the way

that the driver initializes itself. When a driver is statically linked, it

typically links its _init() function into the dev_init chain, and the

_init() function calls the next driver’s _init() function in the chain.

This mechanism is inappropriate for loadable drivers since the dev_init