When a configuration is replaced by another with different metadata,
disconnect signals and clear @best_conf pointers. Also, the check in
remove_ip_config() was wrong.
Fixes: 8e6d442477
Fixes: 570d73979b
To allow the execution of asynchronous actions before the system is
suspended, add a mechanism for delaying the drop of inhibitor lock.
Clients can supend the suspension by calling inhibit_take() in their
handler for SLEEPING signal and use inhibit_release() later when they
are done.
We take a "delay" type inhibitor lock, which means that the system
will proceed anyway after a certain amount of time.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
Use the ipvx.dns-priority when sorting the array of
configurations. When a negative value is found, all following entries
with a greater value are skipped.
Fall back to system default value for ipvx.dns-priority when it's zero
in the setting. For VPNs the default value is 50; for other
connections is 100, but it depends also on the content of
[connection*] sections in NetworkManager.conf.
In a following commit configurations will be ordered by their
priority; arrange them in a single array to make this simpler. Also,
instead of using g_object_set_data() to store metadata, introduce a
NMDnsIPConfigData structure.
If the initial hash includes the global configuration, every update
attempt will be skipped because the configuration never changes, and
resolv.conf will never be updated. Instead, use a NULL global
configuration to compute the hash and force an initial update.
It's not enough to consider IF_LOWER_UP flag. Instead,
the important flag is actually IF_UP.
Actually, I suspect that IF_LOWER_UP is not needed. But for
now leave it, in order not to break something.
This is especially important, because changing MTU takes the
link down for a moment. Taking a link down deletes IP routes and
IPv6 addresses. Thus, when the link comes up again, we must restore
them.
Otherwise, we don't call merge_and_apply() until the next DHCP lease
(or possibly never in case of static addressing).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
nm_device_set_ip4_config() is called during cleanup and
from ip4_config_merge_and_apply(). The latter, has several
call sites.
It's not easy to track whether we called set_ip4_config with
or without commit (and if we call it without commit, we might
not see a logging line at all).
(same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
Most logging lines already had a prefix like "(%s): ". With this change,
the prefix gets added automatically by the logging macro.
Other logging lines didn't have a prefix. But since we no longer log the
file location, it's not nice to see messages without prefix/location.
priv->ctx->cancellable is passed to mm_sim_send_pin() to cancel the
operation.
We must cancel the operation when the context/response is no longer
relevant.
Especially, as we don't take a reference on @self during the asyncronous
request.
We would subscribe to config-changed signal during object-realize,
however only unsubscribe during dispose().
Avoid multiple subscributions, and unsubscribe also when unrealizing
the device.
Also, always subscribe to the signal, even without capability
NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read
capabilities later on, so just always subscribe.
Contrary to gboolean, bool is only one byte in size.
Due to alignment and ordering of the fields, this saves
merely 16 bytes per NMDevicePrivate struct (on x86_64),
still.
Also, bool is coerced by the compiler to be strictly FALSE or
TRUE -- contrary to gboolean, which can be any integer.
Thus, for bool type, "g_assert (NM_IN_SET (value, FALSE, TRUE));"
never fails. That is desirable as well.
While not a large win, it seems favorable to use bool type for
fields of a struct.
... and make the structs NMAuthSubject and NMAuthSubjectClass
opaque types.
I don't want to do this for all our types, only for a few prominent
GObject instances that we create a lot and that are really not expected
to ever be subclassed.
NMAuthSubject is such a candidate. It is really a very simple object
containing a few information bits about the authentication request.
It is not ever expected to be extended/inherited or become more
complex. No need to do a full-fledged private-data implementation.
Usually, our _GET_PRIVATE() macros cast away the const-ness of
the self argument -- also because they cannot do any better in
plain (gcc) C.
Now it is possible to preserve const-ness, it seems more correct to do so.
After all, the const should also help us not modifying arguments that are
not intended to be modified.
Although, the more important use of const is to signal that a function
promises not to modify an argument, like in memcpy(void*,const void*)
it's immediately clear which is source and destination. In C, a const
is anyway not enforcable, but can show intent.
Likewise for NM_IP6_CONFIG_GET_PRIVATE() and NMIP6Config.
We don't add such wrappers anywhere else, and I think they are not
desired style.
Also, keep the signal-id in a "gulong session_changed_id", instead of
guint.
With GObject, the object structure and class structure must be public
to be able to inherit from the type. As NMIP4Config is not inherited
(final), we don't need that and we don't expect ever needing that for
this type.
Already now, we want to have the priv pointer directly accessible via
self->priv. The main reason is improved debugging, another reason
is faster lookup.
Now with the struct private, we can directly embed the private data
inside NMIP4Config. This avoids storing the private data outside separately
inside the GObject which involves a small overhead.
It becomes more attractive to do so, as every NMDevice has a multitude of
these NMIP4Config instances.
And likewise for NMIP6Config.
