Managing and Developing Dynamically Loadable Kernel Modules

Developing Dynamically Loadable Kernel Modules

Chapter 12 551

Miscellaneous Modules

Miscellaneous modules can implement any feature within the kernel. As

such, a miscellaneous module's _load() function must address all of the

module's speciﬁc needs. Similarly, the module's _unload() function

must determine for itself if it is safe to unload. The system will not allow

a module to be unloaded if other loaded modules are dependent upon the

module. Other than this check, the system performs no other checks

when the administrator attempts to remove a miscellaneous module

from the kernel.

The argument to the _load() function is not meaningful and should be

ignored.

DLKM Module Development Process

Developing a DLKM module such as a device driver requires more up

front planning than most application programming projects. At the very

least, testing and debugging are more involved, and more knowledge

about hardware is required.

This section describes the procedures for developing a DLKM module.

Since you can include a DLKM module in the system in one of two ways,

either as a Dynamically Conﬁgured Loadable Module or as a Statically

Conﬁgured Loadable Module, this section considers both methods of

inclusion. Complete command line invocations are included in the

detailed descriptions where appropriate.

Developing a DLKM module is an iterative process. You write, test, and

debug a module in a piecemeal fashion, building up to the

implementation of the complete module.

During the ﬁrst phases of development, possible errors in the module

code may panic or damage the system, even parts of the system that may

seem unrelated to your module. Testing should be done when no other

users are on the system and all production data ﬁles are backed up.

Ideally, testing would be performed on a restricted use system set up

speciﬁcally for the purpose of developing kernel modules.

NOTE Before starting the development process, it is always a good idea to make

your own backup of /stand/vmunix for emergency recovery purposes.

Although the kmupdate(1M) command always saves the previous /

stand/vmunix to the kernel name /stand/vmunix.prev, you must be