Managing Kernel Modules with kcmodule

Getting Information About Modules

When you run kcmodule with no options, it shows you the modules on your system, their current state, and the state they will have at next boot. On a typical system, you will see many modules in static state; some modules that are unused, which are often device drivers for hardware your system doesn’t have; and a handful of modules in loaded state. The states are described below.

	NOTE: The kcmodule options are listed in Table 10-1.

When you use the -c (configuration) option, kcmodule displays the module information from a saved configuration instead of the currently running system.

The output of kcmodule can be varied with several options. To control which modules are listed, use the -a (all), -D (differences), and/or -S (set) options. The -a option adds required modules to the output (normally they are omitted). The -D option restricts the output to only those modules whose state at next boot is different from their current state. The -S option restricts the output to modules whose state has been explicitly set (that is, it omits required modules, unused modules, and modules added to satisfy a dependency). The output can also be restricted by listing module names on the command line.

To control the output format, use the -d (description), -v (verbose), or -P (parse) options.

With No Options

With no options, the output looks like this:

# kcmodule KeyboardMUX PCItoPCI autofs cachefs cifs rng vxportal wsio Module State Cause Notes KeyboardMUX unused PCItoPCI static depend autofs static best cachefs auto best auto-loadable, unloadable cifs auto explicit auto-loadable, unloadable rng loaded explicit loadable, unloadable vxportal static explicit auto-loadable, unloadable wsio         static  required

With the -d Option

The -d option adds the description of each module.

# kcmodule -d PCItoPCI cachefs cifs rng Module    State   Cause     Notes     Description PCItoPCI  static  depend         Generic PCI to PCI Bridge Adapter CDIO cachefs   auto    best      auto-loadable, unloadable     Cache File System cifs      auto    explicit  auto-loadable, unloadable     CIFS Client Module rng       loaded  explicit  loadable, unloadable     Strong Random Number Generator

With the -v Option

The -v option gives verbose, multiline information about each module:

# kcmodule -v autofs cachefs Module              autofs  (1.0) Description         Automounter File System Timestamp           Tue Sep 12 21:53:28 2006 [45078EC8] State               static (best state) State at Next Boot  static (best state) Capable             static unused Depends On          module nfswrp:0.0.0                     interface HPUX_11_31_PERF:1.0 Module              cachefs  (1.0) Description         Cache File System Timestamp           Tue Sep 12 21:53:29 2006 [45078EC9] State               auto (best state) State at Next Boot  auto (best state) Capable             auto static loaded unused Depends On          module nfswrp:0.0.0                     module dat:0.0.0                     interface HPUX_11_31_PERF:1.0

With the -P Option

The -P option, which is designed for use by scripts or programs, gives complete control over what information is printed. For more information, see “Parsing Command Output” or the kconfig(5) manpage.

The special keyword ALL displays all the possible categories. Compare with the -v option.

# kcmodule -P ALL autofs cachefs name    autofs desc    Automounter File System version 1.0 timestamp       Tue Sep 12 21:53:28 2006 [45078EC8] state   static cause   best next_state      static next_cause      best capable static unused depend  module nfswrp:0.0.0 depend  interface HPUX_11_31_PERF:1.0 name    cachefs desc    Cache File System version 1.0 timestamp       Tue Sep 12 21:53:29 2006 [45078EC9] state   auto cause   best next_state      auto next_cause      best capable auto static loaded unused depend  module nfswrp:0.0.0 depend  module dat:0.0.0 depend  interface HPUX_11_31_PERF:1.0

Use a comma-separated list with the -P option to display the categories you want.

# kcmodule -P name,desc,version autofs cachefs name    autofs desc    Automounter File System version 1.0 name    cachefs desc    Cache File System version 1.0

Interpreting Module Information

Looking at the sample output in “Getting Information About Modules”, you can see that each module has a name and a textual description. Each module also has a version, which typically looks like 1.0.

A kernel configuration can only use one version of any given module. However, multiple versions may be listed if, for example, your currently running system is using a different version of a module from the one that will be used at next boot. Version numbers are normally omitted from the short listing, but will be included if there’s more than one version of a module.

Each kernel module in the currently running configuration has a state, which describes how the module is being used. The possible states are:

When kcmodule is giving information about the currently running system, and there are configuration changes being held for next boot, kcmodule will list both the current state and the state at next boot. For next boot, the same states are used, with complementary meanings:

When kcmodule is giving information about a saved configuration, the same states are used.

Next to each module state is a Cause that tells why the module is (or will be) in that state. The causes are:

Different modules can support different states. Nearly all modules can be in static state, but only a few support loaded or auto states. Many modules can be in unused state, but required modules cannot. The Capable line in the output shows which states a module supports.

	TIP: To see if a module is required, look to see whether unused appears on the Capable line. If it does, the module is not required.

Modules often have dependencies between them. For example, device drivers typically cannot be configured into the kernel unless the driver support modules are also configured. Dependencies like this are shown on the Depends On lines in the output. A module can be dependent on a particular other module, specified by name and version. A module can also be dependent on an interface that must be supplied by some other module, without saying specifically which modules supply that interface. Modules that supply such interfaces have an Exports line in the output, listing the interfaces they export.

Changing Module States

To change the state of a module, put module state assignments on the kcmodule command line. (Also see “Managing Configurations with System Files”.) For example, to load the CD File System module, named cdfs:

In fact, loaded is the developer-chosen best state for cdfs, so this is the same as:

To unload it:

# kcmodule cdfs=unused

See the kcmodule(1M) manpage for details.

When you change a module state using a command as in the above examples, the change will be made immediately to the currently running system, if possible. Sometimes it’s not possible to make the change immediately; for example, there might be a CD file system mounted, in which case cdfs can’t be unloaded. In those cases, kcmodule will hold the change and apply it at next boot. A change that moves a module into or out of static state can never be applied immediately, and will always be held for next boot. If any change on the kcmodule command line has to be held for next boot, they all will be.

When modules are moved into or out of static state, the kcmodule command will run for quite a while. This is because such changes require that the kernel executable be relinked. If you have multiple such changes to make, it is best that you list them all on the same kcmodule command line, or make the changes in a system file and import it. (See “Managing Configurations with System Files”.) Either of these techniques will ensure that the kernel executable is only relinked once.

Sometimes you may want to force a change to be held for next boot, instead of applying it immediately. In these cases you can use the -h (hold) option with kcmodule to force that behavior. HP recommends that this option be used only when the next boot is expected to be soon. If, for example, the next boot doesn’t happen for months after making such a change, the system administrator could be unpleasantly surprised at the effect of a pending change that had been forgotten.

Changes to saved kernel configurations can be made by using the -c (configuration) option. Such changes are made to the saved configuration immediately, but they won’t affect the running system until that saved configuration is either loaded or booted. See “Managing Saved Configurations with kconfig” for more information.

When changing module states, kcmodule supports the -b (backup) option to specify backup behavior, and the -C option to specify a log file comment. See “Recovering from Errors” and “The Kernel Configuration Log File” for details.