mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-29 19:40:12 +01:00
dfb77e3b19
Since there have not been separate system and user settings services
since 0.8, the "system" in NMSystemConfigInterface is kind of
meaningless. Rename it to NMSettingsPlugin, which describes what it
does better.
This is just:
git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
-e 's/system_config_interface/settings_plugin/g;' \
-e 's/system-config-interface/settings-plugin/g;' \
-e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
-e 's/sc_plugin/settings_plugin/g;' \
-e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
-e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
-e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
-e 's/SCPlugin/SettingsPlugin/g;' \
-e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
$(find src/settings -type f)
(followed by some whitespace fixups in nm-settings-plugin.c, and a
Makefile.am fix for the rename)
|
||
|---|---|---|
| .. | ||
| ibft | ||
| ifcfg-rh | ||
| ifnet | ||
| ifupdown | ||
| keyfile | ||
| Makefile.am | ||
| 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_init(), which when called actually sets up the vtables for the functions defined by NMSettingsPlugin. Thus there are two entry points into the plugin: nm_settings_plugin_factory() and the NMSettingsPlugin methods. The plugin also emits various signals (defined by NMSettingsPlugin) 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.