A SLURM plugin is a dynamically linked code object which is loaded explicitly at runtime by the SLURM libraries. A plugin provides a customized implementation of a well-defined API connected to tasks such as authentication, interconnect fabric, and task scheduling.
A SLURM plugin identifies itself by a short character string formatted similarly to a MIME type: <major>/<minor>. The major type identifies which API the plugin implements. The minor type uniquely distinguishes a plugin from other plugins that implement that same API, by such means as the intended platform or the internal algorithm. For example, a plugin to interface to the Maui scheduler would give its type as "sched/maui". It would implement the SLURM Scheduler API.
SLURM plugin version numbers comprise a major and minor revision number. As SLURM evolves, changes to the individual plugin APIs may be necessary to implement new features. The major number identifies the version of the applicable API that the plugin implements. Incrementing the major version number denotes that the API has changed significantly and possibly incompatibly over prior versions.
Because plugins are separate code objects and perhaps under the control of third parties, version skew may occur in a SLURM installation. SLURM may support multiple versions of each API in a backward-compatible fashion to provide time for plugin authors to update their plugins. Conversely the plugin may support multiple versions of the API in order to be transparently portable across different SLURM installations. The version of the API spoken in an installation will be the highest-numbered version which is common to both SLURM and the plugin. Each SLURM release will document which API versions it supports. From time to time ancient API versions will be deprecated.
The minor version number is incremented at the discretion of the plugin author and denotes revisions or upgrades particular to that implementation. If two or more plugins of the same type are provided in an installation, the plugin with the highest minor revision will be selected.
A plugin must define and export the following symbols:
A plugin may optionally define and export the following symbols:
int init (void);
Description
If present, this function is called just after the plugin is loaded. This allows the plugin to perform any global initialization prior to any actual API calls.
Arguments
None.
Returns
SLURM_SUCCESS if the plugin's initialization was successful. Any other return value indicates to SLURM that the plugin should be unloaded and not used.
void fini (void);
Description
If present, this function is called just before the plugin is unloaded. This allows the plugin to do any finalization after the last plugin-specific API call is made.
Arguments
None.
Returns
None.
N.B. these functions are not the same as those described in the dlopen(3) system library. The C runtime system co-opts those symbols for its own initialization. The system init() is called before the SLURM plugin init(), and the SLURM fini() is called before the system's fini().
The functions need not appear. The plugin may provide either init() or fini() or both.
SLURM is a multithreaded application. The SLURM plugin library may exercise the plugin functions in a re-entrant fashion. It is the responsibility of the plugin author to provide the necessarily mutual exclusion and synchronization in order to avoid the pitfalls of re-entrant code.
The standard system libraries are available to the plugin. The SLURM libraries are also available and plugin authors are encouraged to make use of them rather than develop their own substitutes. Plugins should use the SLURM log to print error messages.
The plugin author is responsible for specifying any specific non-standard libraries needed for correct operation. Plugins will not load if their dependent libraries are not available, so it is the installer's job to make sure the specified libraries are available.