Next: , Up: Plugins

10.1 Plugin mechanism implementation

Each plugin is actually an ELF shared library file.

Shared libraries are libraries that are loaded by programs when they start. When a shared library is installed properly, all programs that start afterwards automatically use the new shared library. It is actually much more flexible and sophisticated than this, because the approach used by Linux permits you to:

For more informations about shared libraries, see for example

However, shared libraries can be loaded not only during program startup, but also manually, by the dlopen() system function. The function loads the library file and returns a handler (or just returns a handler if the library is already loaded). The library symbols can then be accessed via the dlsym function. Thus, the plugin can export functions and variables to the program. Sometimes, the plugin cannot be also unloaded, because it may change the VRR behavior in an irreversible way.

The VRR plugin interface maintains the list of currently loaded plugins, and for each loaded plugin the list of exported functions. The loaded plugin list is maintained as a linked list of struct plugin_rec structures, similarly the function lists. The functions are exported by the plugin itself during initialization. See Rules for writing plugins for programmers usage informations.

The arguments of a plugin function are passed via the union plugin_arg union. The return type of the function must be either void or union plugin_arg. Only a subset of C and VRR data types is allowed in function prototypes, see enum plugin_prototypes for the allowed list. The function arguments are passed as an array of union plugin_arg unions. The function prototype is described to the VRR plugin interface by arguments of the registration plugin_function_register function.

When registering a function via plugin_function_register, the function is exported also to the Scheme interface and it is possible to use it from the Scheme console. See Scheme for implementation details.