HP-UX Reference (11i v2 04/09) - 1M System Administration Commands A-M (vol 3)

k
kcmodule(1M) kcmodule(1M)
Arguments
The arguments to kcmodule may be any mixture of module state queries and assignments. The argu-
ments must each take one of the forms listed below. No spaces are permitted within each argument. If
no arguments are given, kcmodule performs a query on all modules (subject to the constraints of the
-a,
-D,or-S flags).
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, otherwise
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.
uninstall
The module will be put into the unused state. In addition, all of the module’s
tunable settings and other associated configuration data will be purged from
the configuration. This state should be specified only when a module is being
physically removed from the system.
Some modules do not support all of the possible states. To see which states a module supports, run
kcmodule -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, depend-
ing 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, if it has one; otherwise, this field will be
omitted from the output.
state The state of the module. The states are listed in the table under -s, 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 adminis-
trator.
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.
HP-UX 11i Version 2: September 2004 − 2 − Hewlett-Packard Company Section 1M−−345