The idea of NMDevice:realize() was to
(1) update the device properties
(2) fail realization if some critical properties are missing
(1) is already done during nm_device_setup_start().
(2) was only implemented by NMDeviceVlan:realize(), but it
basically was just checking whether such a platform device exists.
Other implementations don't do that either and it opens up for a race
when the device gets deleted externally.
Extract a function update_properties() similar to other device
implementations. It reads the device specific data from platform
and raises property-changed notifications.
update_properties() is now called by realize_start_notify().
NMDeviceVlan:realize() -- which previously implemented something like
update_properties() -- now does nothing. Note that previously
realize() might have failed, but this is different from other device
implementations and it was unclear what a failure really meant.
Ok, it might fail because the link was not found in the platform cache.
But other implementations don't check that either, so why vlan? And
how to handle that properly anyway?
Therefore realize()'s implementation is no longer needed because
nm_device_realize() already calls realize_start_setup(), which
calls realize_start_notify() and update_properties().
update_connection() no longer refreshes the device properties.
Instead it only modifies the passed-in NMConnection. It's a bit
ugly that update_connection() uses both cached properties from
NMDeviceVlan (vlan_id) and platform properties (xgress maps).
Also, update_connection() doesn't return early on error but continues
trying to update the NMConnection. The reason is that update_connection()
cannot return a failure status.
The virtual function NMDevice:realize() is only called by
nm_device_realize() and immediately followed by nm_device_setup_start().
Devices already overwrite setup_start_notify() to update their properties.
No need to duplicate that in realize().
All implementations of NMDevice:setup_start() in derived classes
invoke the parent implementation first. Enforce that by moving
NMDevice:setup_start() to realize_start_setup() and only notify
derived classes afterwards via NMDevice:realize_start_notify().
Reapplying a connection should not be done by iterating over and
(unsorted) @diffs array. Instead the order matters! E.g. first layer 2
before IP settings. Thus extracting those individual updates on a per-setting
base to different reapply_*() functions is more complicated, albeit incorrect
in complex cases. We need full control over how to reapply changes, one
after the other.
Also, once we start applying changes, we cannot really abort on error.
We can only continue best-effort and hope for the best.
Also, always reapply certain settings, even if the configuration doesn't
change. That means, if the user externally deletes a static IP address,
he can call reapply() to restore it. Even though he doesn't provide a
different setting to apply.
Also revert the changes to nm_device_reapply_settings_immediately().
Effectively there is little code that can be reused.
Add audit logging.
The main reason to introduce the "no-wait.d" dispatcher directory was
"10-ifcfg-rh-routes.sh", which (as a pre-up script) delays activation.
We even extracted the script to a separate package on RHEL to avoid
delays by default.
Invoke the script via no-wait.d.
In certain situations, ethernet links first appear with a zero MAC
address and then the MAC changes some time later. Currently NM does
not deal correctly with this scenario since it initializes wrong
@initial_hwaddr and @permanent_hwaddr on the device and tries to
immediately activate it.
To fix this, initialize the device's addresses only when the MAC
becomes valid and make the device available only at that point.
Instead of using a signal for triggering the generation of a default
connection when the device becomes managed, let the manager wait for a
transition to UNAVAILABLE or DISCONNECTED states.
This partially reverts b3b0b46250 ("device: retry creation of
default connection after link is initialized").
We cannot abort the construction of a GLib object instance
like we did for NMDeviceWifi and NMDeviceOlpcMesh when
nm_platform_wifi_get_capabilities() failed.
Instead, check the capabilities first (in the factory method)
and only create the object instance when the device can be handled.
https://bugzilla.gnome.org/show_bug.cgi?id=760154
This is the same as 04c70c76bc for the
NMIP4Config and NMIP6Config structures. The new field makes debugging
of issues related to IP configuration much easier.
We inconsistently use gulong,guint,int types to store signal handler
id, but the type returned by g_signal_connect() is a gulong.
This has no practical consequences because a int/guint is enough to
store the value, however it is better to use a consistent type, also
because nm_clear_g_signal_handler() accepts a pointer to the signal id
and thus it must be always called with the same pointer type.
