mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-28 00:30:09 +01:00
fb191fc282
Currently both bridge.mac-address and ethernet.cloned-mac-address get written to the same MACADDR ifcfg-rh variable; the ethernet property wins if both are present. When one property is set and the connection is saved (and thus reread) both properties are populated with the same value. This is wrong because, even if the properties have the same meaning, the setting plugin should not read something different from what was written. Also consider that after the following steps: $ nmcli con mod c ethernet.cloned-mac-address 00:11:22:33:44:55 $ nmcli con mod c ethernet.cloned-mac-address "" the connection will still have the new mac address set in the bridge.mac-address property, which is certainly unexpected. In general, mapping multiple properties to the same variable is harmful and must be avoided. Therefore, let's use a different variable for bridge.mac-address. This changes behavior, but not so much: - connections that have MACADDR set will behave as before; the only difference will be that the MAC will be present in the wired setting instead of the bridge one; - initscripts compatibility is not relevant because MACADDR for bridges was a NM extension; - if someone creates a new connection and sets bridge.mac-address NM will set the BRIDGE_MACADDR property instead of MACADDR. But this shouldn't be a big concern as bridge.mac-address is documented as deprecated and should not be used for new connections. https://bugzilla.redhat.com/show_bug.cgi?id=1516659 |
||
|---|---|---|
| .. | ||
| ibft | ||
| ifcfg-rh | ||
| ifnet | ||
| ifupdown | ||
| keyfile | ||
| 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.