kcmodule man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

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  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 ALSO
       kclog(1M), kconfig(5).

       available on

								  kcmodule(1M)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net