Specifications

D
evice Driver Programming
13-14
Unloading the Module 13
The -u and -U options instruct modadmin to unload a module from the running system.
For example, the command
modadmin -U lp
unloads the lp driver by specifying its module name, and the command
modadmin -u module-id
unloads the lp driver by specifying the module-id returned by the -l option.
If lp is currently in-use (that is, its hold count is not equal to 0), or if another loaded mod-
ule references symbols in lp (that is, its dependent count is not equal to 0), the request to
unload the lp driver fails. If this occurs, DLM makes the module a candidate for subse-
quent auto unload.
For a complete description of the modadmin command line options, refer to the
modadmin(1M) manual page.
Debugging a Loadable Module 13
DLM Error Messages 13
DLM error messages are written to the kernel's putbuf message buffer; some of the mes-
sages are also written to the console. When a module fails to load and no detailed error
message is displayed on the console, you can often determine the cause of the error by
printing the messages in the putbuf.
This buffer can be examined while in the kernel debugger kdb by dumping its contents.
For information about kdb, refer to the kdb(1M) manual page.
Dynamic Symbols and kdb 13
As a consequence of the DLM feature, a dynamic symbol table is now maintained in
kernel address space. The dynamic symbol table contains all global symbols defined in the
static kernel—plus all global symbols defined in all currently loaded modules. The
contents of the dynamic symbol table change as modules are loaded and unloaded; when a
module is loaded, its symbolic information is added to the table, and when the module is
unloaded, its symbolic information is deleted.
Note that the symbols defined in loadable modules are not known to kdb until they have
been successfully relocated and resolved during loading. When debugging routines called
during a DLM load operation (such as _load, init or start), it is useful to have
access to the module's symbols as soon as possible.
The best way to do this in kdb is to break upon return from the DLM routine
mod_obj_load() in modld(), and then single step until the symbol availability flag is
set (about 10 instructions). Once available, the loadable module's symbols can be accessed
in the same manner as you would access any other kernel symbol.
For information about the dynamic symbol table, refer to the getksym(2) manual page.