HP-UX Reference (11i v3 07/02) - 1M System Administration Commands A-M (vol 3)

k
kcmodule(1M) kcmodule(1M)
module The state of the module will be reported. No change is made.
module= The module will be put into its
best state.
module=state The module will be put into the specified state. The possible states are:
unused The module is not used in any way.
static The module is statically bound into the kernel executable.
auto The module will be dynamically loaded into the kernel when something tries to
use it.
loaded The module is dynamically loaded into the kernel.
best The module will be put into the state identified by the kernel module developer
as its "best" state. Typically this will be
auto, if supported by the module, oth-
erwise
loaded, if supported by the module, otherwise
static. Note that a
module in
best state will inherit any changes that HP makes to the "best"
state for a module, in a patch or a future release of HP-UX.
Some modules do not support all of the possible states. To see which states a module supports, run
kcmo-
dule -v
modulename.
Moving modules into or out of the static state requires a kernel relink, so such changes cannot be
applied without a system reboot. Other module state changes may also require a system reboot, depending
on the nature of the specified module.
Moving a module from loaded to auto has no effect on the currently running system; the module
remains loaded. It will be autoloaded on first use after future reboots.
Developer’s Note
The layout and content of kcmodule’s output may change without notice, except when -P fields is
specified. Scripts or applications that need to parse the output of
kcmodule are expected to use the
-P
fields option. See kconfig(5) for details.
The fields supported in a kcmodule request are:
name The name of the module.
alias This field will produce a line in the output for each alternate name for the
module. (There may be zero such lines.)
desc A short description of the module.
version The version number of the module.
timestamp The modification timestamp of the module file.
state The state of the module. The states are listed in the table under Arguments,
above.
cause This field indicates how the module got into its current state. It will have one of
the following values:
explicit The module was explicitly put in its current state by the administra-
tor.
auto The module was put in auto state by the administrator. An
attempt was made to use the module, so it has been automatically
loaded.
depend The module inherited its state from another module that depends
on it.
required The module is in use because it is marked required.
best The module is in this state because it is the "best" state for this
module as specified by the module developer.
next_state The state of the module at next boot. This field is present only if -c is not
specified.
next_cause This field indicates how the module was given its state for next boot. It has the
same values as cause, above. This field is present only if -c is not specified.
HP-UX 11i Version 3: February 2007 − 2 − Hewlett-Packard Company 387