Managing Systems and Workgroups: A Guide for HP-UX System Administrators

Configuring a System
Reconfiguring the Kernel (HP-UX 11i Version 2)
Chapter 3328
Different modules can support different states. Nearly all modules can
be in static state, but only a few support loaded or auto states. Many
modules can be in unused state, but required modules cannot. The
“Capable” line in the output shows which states a module supports.
(Hint: to see if a module is required, look to see whether unused appears
on the “Capable” line. If it does, the module is not required.)
Modules often have dependencies between them. For example, device
drivers typically cannot be configured into the kernel unless the driver
support modules are also configured. Dependencies like this are shown
on the “Depends On” lines in the output. A module can be dependent on a
particular other module, specified by name and version. A module can
also be dependent on an interface that must be supplied by some other
module, without saying specifically which modules supply that interface.
Modules that supply such interfaces have an “Exports” line in the
output, listing the interfaces they export.
Changing Module States
To change the state of a module, put module state assignments on the
kcmodule command line. (Also see “Managing Configurations with
System Files” on page 356.) For example, to load the CD File System
module, named cdfs:
# kcmodule cdfs=loaded
In fact, loaded is the developer-chosen best state for cdfs, so this is the
same as:
# kcmodule cdfs=best
To unload it:
# kcmodule cdfs=unused
best The system administrator chose to use the module, but
didn’t choose a specific state, so the module is in its “best”
state as determined by the module developer.
auto The module was in auto state, and was automatically
loaded when something tried to use it.
required The module was marked required by its developer.
depend The module is in use because some other module in the
configuration depends on it.