Module Manager

The Module Manager is tasked with loading and unloading modules as well as managing the plug-in message processing.

When a module is successfully loaded, it registers one or more plug-ins. The Module Manager creates a new thread for each of these plug-ins. Then the initialization message to the plug-in is sent and the message dispatch loop is started in this new thread. Having each plug-in in a separate thread prevents one plug-in from "hanging" other plug-ins and the user interface.

Note:

For compatibility with future versions of Network Identity Manager, a plug-in should not depend on the fact that it is running in its own thread.

Read more :

• Structure of a module

Module Load Sequence

When kmm_load_module() is called to load a specific module, the following sequence of events occur:

• The registration information for the module is located on the registry key \Software\MIT\NetIDMgr\PluginManager\Modules\[ModuleName].

  See also:

  config

• The module will not be loaded if one of the following conditions are true:
  • The Disabled value is defined and non-zero.

  • The FailureCount value is defined and exceeds the maximum failure count. By default, the maximum failure count is three, although it can be set by adding the registry value ModuleMaxFailureCount in registry key Software\MIT\NetIDMgr\PluginManager\Modules .

• The ImagePath value from the registration information is used to locate the module binary. If it is not an absolute path, then the binary is located using the standard system search path starting from the directory in which Network Identity Manager binaries are located.

• The binary is loaded into the address space of Network Identity Manager along with any dependencies not already loaded.

• If the Network Identity Manager core binary is signed, then the signature is checked against the system and user certificate stores. If this fails, the module is unloaded. See Unload sequence.

• The init_module() entry point for the loaded module is called. If this function returns an error or if no plug-ins are registered, then the module is immediately unloaded. See Unload sequence.
  • During processing of init_module(), if any localized resource libraries are specified using kmm_set_locale_info(), then one of the localized libraries will be loaded. See Localization

  • During processing of init_module(), the module registers all the plug-ins that it is implementing by calling kmm_provide_plugin() for each.

• Once init_module() returns, each plug-in is initialized. The method by which a plug-in is initialized depends on the plug-in type. The initialization code for the plug-in may indicate that it didn't initialize properly, in which case the plug-in is immediately unregistered. No further calls are made to the plug-in.

• If no plug-in is successfully loaded, the module is unloaded. See Unload sequence.

During normal operation, any registered plug-ins for a module can be unloaded explicitly, or the plug-in itself may signal that it should be unloaded. If at anytime, all the plug-ins for the module are unloaded, then the module itself is also unloaded unless the NoUnload registry value is set in the module key.

Unload sequence

• For each of the plug-ins that are registered for a module, the exit code is invoked. The method by which this happens depends on the plug-in type. The plug-in is not given a chance to veto the decision to unload. Each plug-in is responsible for performing cleanup tasks, freeing resources and unsubscribing from any message classes that it has subscribed to.

• Once all the plug-ins have been unloaded, the exit_module() entry point is called for the module.

• If any localized resource libraries were loaded for the module, they are unloaded.

• The module is unloaded.

The following diagram illustrates the relationship between modules and plug-ins as implemented in the Kerberos 5 plug-in distributed with Network Identity Manager.

---