Managing and Developing Dynamically Loadable Kernel Modules

Developing Dynamically Loadable Kernel Modules

Chapter 12 527

loaded in a certain phase of the booting process. The supported loading

phase for a module is speciﬁed in the module’s master ﬁle. A module can

have more than two supported loading phases deﬁned concurrently. If no

phases are speciﬁed in the master ﬁle, the module is loaded during run-

time.

The conﬁgured loading phase speciﬁes the phase in which the module

needs to be loaded. The conﬁgured loading phase for a module is speciﬁed

in its system ﬁle and the valid values are as follows:

BOOT1 attempt to load the module during boot phase 1

BOOT2 attempt to load the module during boot phase 2

INIT kminit rc script will attempt to load the module

AUTO the module remains ready to load on demand or via the

DLKM auto-load mechanism

The module can specify BOOT1 or BOOT2 for its conﬁgured loading phase

only when it also has BOOT1 or BOOT2 (or both) speciﬁed in its supported

loading phase. Otherwise the module conﬁguration process will complain

about this module.

NOTE Only miscellaneous modules (MISC) can be registered during boot phase

1 on Itanium-based systems. Other DLKM types supportedin HP-UX 11i

Version 1.5 will not work properly in early boot. When their type-speciﬁc

registration is performed, the needed functionality will not be available

during the early phases of booting, (i.e., streams, wsio, etc.).

Modules conﬁgured as INIT will attempt to be loaded by the kminit rc

script. This is identical to the procedure for DLKMs in the HP-UX 11.0

release, which attempts to load the modules that are registered in the /

etc/loadmods ﬁle.

Modules conﬁgured as AUTO are not loaded automatically in any of the

phases unless they are referenced as a dependent of another module(s).

If they are not referenced during the boot or init phases as a dependent,

then they will be registered during boot phase 2. However they will not

be explicitly loaded when the system is re-booted. They will remain

ready to load on demand (kmadmin -L), or on access, for module types

supporting the auto-load mechanism.