Managing and Developing Dynamically Loadable Kernel Modules

Developing Dynamically Loadable Kernel Modules

Chapter 12556

NOTE You may be able to use the ioscan and insf commands to install special

ﬁles in the /dev directory. If no options are speciﬁed, insf creates special

ﬁles for all new devices in the system. New devices are those devices for

which no special ﬁles have been previously created. See the ioscan (1M)

and insf (1M) manual pages for more details.

Testing the Module

Testing a DLKM module consists of testing all of its functions under a

variety of operating conditions and for both conﬁgurations: dynamically

loadable and statically linked. Debugging a module is largely a process of

analyzing the code to determine what could have caused a given

problem.

The most common debugging technique is monitoring the kernel code

using the printf() function to print statements included in the module

source code so that you know what your module is doing during run-time

operation. There are also debuggers such as Q4 to examine the kernel

code. See the Q4 description ﬁle in the /usr/contrib/doc directory for

more detail.

You can use a combination of C preprocessor macros, conditional

compilation, and control variables to turn printf() messages on or off.

The sample template character driver, “dlclass.c” on page 561, includes a

control variable named dlclass_debug to determine whether or not to

generate the messages. All of the messages can be disabled at once by

using kmtune -s to change the value of dlclass_debug to 0 before

conﬁguring dlclass.

Correcting Errors in the Module’s Component Files

Correcting errors in the DLKM module is largely a process of analyzing

the code to determine what could have caused a given problem. Some

common errors are as follows:

❏ Coding problems

❏ Installation problems

❏ Data structure problems

❏ Timing errors