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 http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/.
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.