mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-28 14:30:09 +01:00
8e9f782082
A GObject interface, like a class, has two different C types associated with it; the type of the "class" struct (eg, GObjectClass, GFileIface), and the type of instances of that class/interface (eg, GObject, GFile). NetworkManager was doing this wrong though, and using the same C type to point to both the interface's class struct and to instances of the interface. This ends up not actually breaking anything, since for interface types, the instance type is a non-dereferenceable dummy type anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type containing members "start", "device_added", etc, then you should not be using an NMDeviceFactory* to point to an object that does not contain those members. Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface and NMDeviceFactory; by splitting NMConnectionProvider into NMConnectionProviderInterface and NMConnectionProvider; and by splitting NMSettingsPlugin into NMSettingsPluginInterface and NMSettingsPlugin; and then use the right types in the right places. As a bonus, this also lets us now use G_DEFINE_INTERFACE.
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
|
|
NMSettingsPlugin 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_settings_plugin_factory(). That function creates and returns a singleton
|
|
instance of the plugin's main object, which implements NMSettingsPlugin.
|
|
That interface is implemented via the object definition in G_DEFINE_TYPE_EXTENDED
|
|
in plugin.c, which registers the interface setup function
|
|
settings_plugin_interface_init(), which when called actually sets up the vtables
|
|
for the functions defined by NMSettingsPluginInterface. Thus there are two
|
|
entry points into the plugin: nm_settings_plugin_factory() and
|
|
the NMSettingsPluginInterface methods.
|
|
|
|
The plugin also emits various signals (defined by NMSettingsPluginInterface)
|
|
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.
|