mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-06-06 14:08:29 +02:00
e700211f00
The 'example' settings plugin is (obviously) unused, but it is also
badly maintained and no longer best-practice in several ways:
- it directly reads "NetworkManager.conf" instead of using NMConfig.
- it parses device specs itself, instead of using
nm_match_spec_split().
- read_connections() doesn't ensure that loading a file
does not replace a previously loaded one (due to conflicting
UUID). In general the example doesn't show/handle the complexity
of potential UUID conflicts.
Instead of fixing these issues it is better to ensure our main plugin
('keyfile') corresponds to current best practices. Should we ever add a
new pluginww, 'keyfile' should be the example.
33 lines
1.9 KiB
Text
33 lines
1.9 KiB
Text
Plugins generally have three components:
|
|
|
|
1) plugin object: manages the individual "connections", which are
|
|
just objects wrapped around on-disk config data. The plugin handles requests
|
|
to add new connections via the NM D-Bus API, and also watches config
|
|
directories for changes to configuration data. Plugins implement the
|
|
NMSystemConfigInterface interface. See plugin.c.
|
|
|
|
2) "connections": subclasses of NMSettingsConnection. They handle updates to
|
|
configuration data, deletion, etc. See NMKeyfileConnection.
|
|
|
|
3) reader/writer code: typically a separate static library that gets linked
|
|
into the main plugin shared object, so they can be unit tested separately
|
|
from the plugin. This code should read config data from disk and create
|
|
an NMConnection from it, and be capable of taking an NMConnection and writing
|
|
out appropriate configuration data to disk.
|
|
|
|
NM will first call the "factory" function that every module must provide, which
|
|
is nm_system_config_factory(). That function creates and returns a singleton
|
|
instance of the plugin's main object, which implements NMSystemConfigInterface.
|
|
That interface is implemented via the object definition in G_DEFINE_TYPE_EXTENDED
|
|
in plugin.c, which registers the interface setup function
|
|
system_config_interface_init(), which when called actually sets up the vtables
|
|
for the functions defined by NMSystemConfigInterface. Thus there are two
|
|
entry points into the plugin: nm_system_config_factory() and
|
|
the NMSystemConfigInterface methods.
|
|
|
|
The plugin also emits various signals (defined by NMSystemConfigInterface)
|
|
which NetworkManager listens for. These include notifications of new
|
|
connections if they were created via changes to the on-disk files. The
|
|
"connection" objects can also emit signals (defined by the NMSettingsConnection
|
|
and NMConnection superclasses) when the connections' backing storage gets
|
|
changed or deleted.
|