kcmodule(1M)															      kcmodule(1M)

NAME

       kcmodule - 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 mod-
       ules 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 run-
	      ning kernel configuration.

	      See kconfig(5) for more information on saved kernel configurations.

       The specified
	      comment  will be included in the kernel configuration log file entry made for this invocation of For more details on the kernel con-
	      figuration log file, see kclog(1M).  Note that it will usually be necessary to quote the comment in order to avoid interpretation 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 module, 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 assignments.  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 executable.

		      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.  Typically this will be if supported by the module, otherwise  if  supported
				by  the  module,  otherwise 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  out-
       put 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 automatically 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 immediate value change has been made during the current invocation of

	      The cause of the module state before the current change.
		     This field is present only for modules for which an immediate value change has been made during the current invocation 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 ver-
		     sion 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
       configuration 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 configuration.  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 currently 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 module 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 ALSO

       kclog(1M), kconfig(5).

       available on

																      kcmodule(1M)