mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-15 09:30:18 +01:00
46fad1fdb6
The ifcfg-rh plugin provides its own D-Bus service which initscripts query to determine whether NetworkManager handles an ifcfg file. Rework the D-Bus glue to hook GDBus with NetworkManager to use GDBusConnection directly. Don't use generated code, don't use GDBusInterfaceSkeleton. We still keep "src/settings/plugins/ifcfg-rh/nm-ifcfg-rh.xml" and still compile the static generated code. We don't actually need them anymore, maybe the should be dropped later. This is a proof of concept for reworking the D-Bus glue in NetworkManager core to directly use GDBusConnection. Reworking core is much more complicated, because there we also have properties, and a class hierarchy. Arguably, for the trivial ifcfg-rh service all this hardly matters, because the entire D-Bus service only consists of one method, which is unlikely to be extended in the future. Now we get rid of layers of glue code, that were hard to comprehend. Did you understand how nm_exported_object_skeleton_create() works and uses the generated code and GDBusInterfaceSkeleton to hook into GDBusConnection? Congratulations in that case. In my opinion, these layers of code don't simplify but complicate the code. The change also reduces the binary size of "libnm-settings-plugin-ifcfg-rh.so" (build with contrib/rpm --without debug) by 8312 bytes (243672 vs. 235360). |
||
|---|---|---|
| .. | ||
| ibft | ||
| ifcfg-rh | ||
| ifupdown | ||
| keyfile | ||
| meson.build | ||
| README | ||
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.