Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc UPDATE added explanations to plugins #2298

Merged
merged 1 commit into from
Sep 11, 2024
Merged

doc UPDATE added explanations to plugins #2298

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions src/plugins.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,19 +38,22 @@ extern "C" {
* Furthermore, there are several internal plugins, implementing built-in data types and selected derived types and YANG
* extensions. These internal plugins uses the same API and can be taken as examples for implementing user plugins. Internal
* plugins are always loaded with the first created [context](@ref howtoContext) and unloaded with destroying the last one.
* The external plugins are in the same phase loaded from the default directories specified at compile time via cmake
* variables `PLUGINS_DIR` (where the `extensions` and `types` subdirectories are added for each plugin type) or separately
* via `PLUGINS_DIR_EXTENSIONS` and `PLUGINS_DIR_TYPES` for each plugin type. The default directories can be replaced runtime
* using environment variables `LIBYANG_TYPES_PLUGINS_DIR` and `LIBYANG_EXTENSIONS_PLUGINS_DIR`.
* The external plugins are in the same phase loaded as dynamic shared objects (shared libraries) from the default directories
* specified at compile time via cmake variables `PLUGINS_DIR` (where the `extensions` and `types` subdirectories are added
* for each plugin type) or separately via `PLUGINS_DIR_EXTENSIONS` and `PLUGINS_DIR_TYPES` for each plugin type. The default
* directories can be replaced runtime using environment variables `LIBYANG_TYPES_PLUGINS_DIR` and `LIBYANG_EXTENSIONS_PLUGINS_DIR`.
* There is also a separate function ::lyplg_add() to manually add a plugin (dynamic shared object) anytime later.
* Another option to manually add an external plugin is using the ::lyplg_add_extension_plugin() or ::lyplg_add_type_plugin()
* which is useful when loading a dynamic shared object is problematic. These functions allow for setting the necessary callbacks
* for the plugin at runtime.
*
* Order of the plugins determines their priority. libyang searches for the first match with the extension and type, so the
* firstly loaded plugin for the specific item is used. Since the internal plugins are loaded always before the external
* plugins, the internal plugins cannot be replaced.
*
* There is also a separate function ::lyplg_add() to add a plugin anytime later. Note, that such a plugin is being used
* after it is added with the lowest priority among other already loaded plugins. Also note that since all the plugins are
* unloaded with the destruction of the last context, creating a new context after that starts the standard plugins
* initiation and the manually added plugins are not loaded automatically.
* Note, that manually added plugin via lyplg_add*() function is added with the lowest priority among other already loaded plugins.
* Also note that since all the plugins are unloaded with the destruction of the last context, creating a new context after that
* starts the standard plugins initiation and the manually added plugins are not loaded automatically.
*
* The following pages contain description of the API for creating user plugins.
*
Expand Down
Loading