kcmodule(1M)kcmodule(1M)NAMEkcmodule - manage kernel modules and subsystems
SYNOPSIS
behavior] config] comment] fields]
[module[unused|static|loaded|auto|best]]] ...
DESCRIPTION
is the administrative command for HP-UX kernel modules. It gives
information about kernel modules and their usage, and makes changes to
their usage.
This command can work with any saved kernel configuration, or with the
currently running kernel configuration, depending on the use of the
flag (see below). By default, changes to the currently running kernel
configuration are applied immediately. Some changes cannot be applied
without a reboot; if any such changes are requested, or the flag is
given, all changes on the command line will be held until next boot.
Only users with appropriate privileges can make changes to module
usage.
Options
Include all modules in the output listing. Normally only "interesting"
modules are listed: required modules and multiple versions of modules
are omitted. Not valid in combination with or
Specifies whether or not to update the automatic backup
configuration before the requested change. Also specifies the
default backup behavior for future changes. See kconfig(5) for
a description of the various backup behaviors. Not valid in
combination with
For compatibility with old releases, is accepted as an alias for
and is accepted as an alias for These aliases will be removed in
a future release.
Tells to view or change the saved kernel configuration named config.
If this option is not specified, views or changes the currently
running kernel configuration.
See kconfig(5) for more information on saved kernel configura‐
tions.
The specified
comment will be included in the kernel configuration log file
entry made for this invocation of For more details on the kernel
configuration log file, see kclog(1M). Note that it will usu‐
ally be necessary to quote the comment in order to avoid inter‐
pretation by the shell.
Adds the description of each module to the output.
Restricts the output to only those modules that have a state change
being held for next reboot. will return 1 if there are any such
modules; see below. Not valid in combination with or
Changes will be held until next boot, even if they could be applied
immediately. Not valid in combination with
Tells to include only the specified fields in its output, and to print
them in the machine-readable form described in kconfig(5). See
the below. Not valid in combination with or
Only modules in non-default states are included in the output. In
other
words, the listing includes only optional modules that are in
use by explicit request. It does not include unused modules,
required modules, or modules that were automatically selected to
resolve dependencies. Not valid in combination with or
Print verbose information about each module.
The information includes the name, version and state of the mod‐
ule, its allowed states and its dependencies on other modules
and interfaces. Not valid in combination with or
Arguments
The arguments to may be any mixture of module state queries and assign‐
ments. The arguments must each take one of the forms listed below. No
spaces are permitted within each argument. If no arguments are given,
performs a query on all modules (subject to the constraints of the or
flags).
module The state of the module will be reported. No change is
made.
The module will be put into its
state.
module=state The module will be put into the specified state. The
possible states are:
The module is not used in any way.
The module is statically bound into the kernel exe‐
cutable.
The module will be dynamically loaded into the kernel
when something
tries to use it.
The module is dynamically loaded into the kernel.
The module will be put into the state identified by the
kernel
module developer as its "best" state. Typi‐
cally this will be if supported by the module,
otherwise if supported by the module, other‐
wise Note that a module in 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
Moving modules into or out of the 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 to 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 output may change without notice, except when
is specified. Scripts or applications that need to parse the output of
are expected to use the option. See kconfig(5) for details.
The fields supported in a request are:
The name of the module.
This field will produce a line in the output for each alternate
name
for the module. (There may be zero such lines.)
A short description of the module.
The version number of the module.
The modification timestamp of the module file.
The state of the module. The states are listed in the table
under
above.
This field indicates how the module got into its current state.
It
will have one of the following values:
The module was explicitly put in its current state by the
administrator.
The module was put in
state by the administrator. An attempt was
made to use the module, so it has been auto‐
matically loaded.
The module inherited its state from another module that
depends on it.
The module is in use because it is marked required.
The module is in this state because it is the "best"
state for this
module as specified by the module developer.
The state of the module at next boot. This field is present
only if
is not specified.
This field indicates how the module was given its state for next
boot.
It has the same values as above. This field is present
only if is not specified.
The state of the module before the current change.
This field is present only for modules for which an imme‐
diate value change has been made during the current invo‐
cation of
The cause of the module state before the current change.
This field is present only for modules for which an imme‐
diate value change has been made during the current invo‐
cation of
This field will contain a space-separated list of the states
that this
module can support. The states are listed in the table
under above.
This field will produce a line in the output for each dependency
this
module has on another module or interface. (There may be
zero such lines.) Each line has the form:
where type is either or indicating the type of object;
name is the name of the interface or module; and version
is the version number of the interface or module on which
this module depends.
This field will produce a line in the output for each interface
exported
by this module. (There may be zero such lines.) Each
line will contain the of an interface exported by this
module.
The special field name may be specified to indicate that all defined
fields should be included in the output. The output may include fields
not listed in this man page. The fields will be listed in unspecified
order.
Additional fields may be added in future releases or patches.
Default Output
When is called with no options, it shows the optional kernel modules on
the system, their current state, the cause for including it in the con‐
figuration and special capabilities if any. If there are changes that
are being held for nextboot, they will be shown as well. The cause
field will be empty for all modules that are not included in the con‐
figuration. The special capabilities of kernel modules would be one
of:
The module can be dynamically changed to the state
The module can be dynamically changed to the state
The module supports the state
The layout and content of the default output may change in future
releases or patches of HP-UX. Scripts or applications which need to
parse the output of must use the option to get output that can be
parsed.
RETURN VALUE
returns one of the following values:
0 was successful. If was specified, this return value indicates
that there are no module state changes being held for next boot.
1 was successful. However, there were changes requested to the cur‐
rently running system which cannot be applied until the system
reboots. Therefore, all of the requested changes are being held
until next boot.
If was specified, this return value indicates that there are mod‐
ule state changes being held for next boot.
2 was not successful.
EXAMPLES
To see all optional modules and their current states:
To see all modules, including required modules, and their current states:
To see verbose information about a module:
To load a dynamic module:
To unload a dynamic module immediately:
To stop using a module when the system reboots:
To bind a module into the static kernel:
SEE ALSOkclog(1M), kconfig(5).
available on
kcmodule(1M)