We will rework NMClient entirely. Then, the synchronous initialization will also use
the asynchronous code paths. The difference will be that with synchronous initialization,
all D-Bus interaction will be done with an internal GMainContext as current thread default,
and that internal context will run until initialization completes.
Note that even after initialization completes, it cannot be swapped back to the user's
(outer) GMainContext. That is because contexts are essentially the queue for our
D-Bus events, and we cannot swap from one queue to the other in a race
free manner (or a full resync). In other words, the two contexts are not in sync,
so after using the internal context NMClient needs to stick to that (at least, until
the name owner gets lost, which gives an opportunity to resync and switch back to the
user's main context).
We thus need to hook the internal (inner) GMainContext with the user's (outer) context,
so when the user iterates the outer context, events on the inner context get dispatched.
Add nm_utils_g_main_context_create_integrate_source() to create such a GSource for
integrating two contexts.
Note that the use-case here is limited: the integrated, inner main context must
not be explicitly iterated except from being dispatched by the integrating
source. Otherwise, you'd get recursive runs, possible deadlocks and general
ugliness. NMClient must show restrain how to use the inner context while it is
integrated.
Some compilers don't convert arrays as _Generic() type selectors to
their pointer type. That means, for those compilers the generic type
would be an array and not a pointer. Work around that by adding zero
to the pointer/array argument.
Also, I cannot get this to work with "clang-3.4.2-9.el7". Disable it
for that compiler. The value of the generic check is anyway that it only
needs to work with some compiler combinations. That will trigger a
compilation failure and we can fix the implementation also for compilers
that don't support the macro.
See-also: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1930.htm
There are two macros: NM_GOBJECT_PROPERTIES_DEFINE_BASE() and
NM_GOBJECT_PROPERTIES_DEFINE(). The former just defines the
property enums and the obj_properties array. The latter also
defines the functions _notify() and _nm_gobject_notify_together_impl().
That means, depending on whether you actually use _notify(), you have
to choose one of the macros. I think that is unnecessarily cumbersome.
Let's mark the function as _nm_unused so that the compiler doesn't
complain about the unused function. I don't think it's a problem
to use NM_GOBJECT_PROPERTIES_DEFINE() even if you don't actually use
_notify().
warning: extra tokens at the end of %endif directive in line 717: %endif # end autotools
warning: extra tokens at the end of %endif directive in line 775: %endif # end autotools
Previously, our "internal" DHCPv4 client is based on a fork of
systemd code. This manner of maintaining the fork is problematic.
The solution is to use a proper library: n-dhcp4 from the nettools
project.
We already have these two as undocumented plugins available, by
setting either "dhcp=systemd" or "dhcp=nettools". This is only for
testing. Users are only supposed to use the "internal" plugin.
Up until now, the "internal" DHCPv4 plugin was based on "systemd" code.
Change that to use "nettools" instead.
Possibly this breaks something, and we need to fix it. But do this
early so we have time to test the nettools plugin and identify issues.
For the user, this change should be entirely transparant.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/302
- the variables in meson.build and in the meson-post-install.sh script
should have the same names.
- the positional command line arguments should be assigned to variables,
because the variable name acts like a documentation what the variable
means (contrary to the argument number).
- the boolean flags should not map to other special values, like
"enable_docs ? 'install_docs' : ''". The name "enable_docs" is
good already, it shall be either passed as 1 or 0 and use the name
consistently.
We don't need such data duplicated. The build setup should
have only one configuration_data() for patching such values.
Now we only have one global, immutable data_conf dictionary with
configuration values. Note that none of the users of data_conf uses all
entries, but as the entries are basically only dependent on the
meson/configure option and valid for the entire project, this simplifies
to handling.
The dependencies of make are exectured in the order as they appear.
We probably should start by creating the directories, before invoking
other install hooks. Currently there is no difference, because none of
the other hooks depend on the base directories. Still split it to
a special target.
$(data_edit) will be used later at an earlier place in the
makefile (to edit "clients/cloud-setup/nm-cloud-setup.service",
which will be handled earlier). Move it.
Also minor cleanups, like allowing to incrementally build
systemdsystemunit_DATA variable.
We preferably should use our convenience macros like _LOGD().
Since those macros expand to _NMLOG() (which needs to be defined
separately), we can move it to "nm-logging-fwd.h" and reuse.
I guess, if you write portable applications, then GIOChannel makes a lot of sense.
But we know that this is on Linux. We don't need to pretend that we
cannot poll on the file descriptor directly.
Curl documents about CURLMOPT_TIMERFUNCTION:
The timer_callback will only be called when the timeout expire time is
changed.
That means, we should not cancel the timeout when it happend, but
only when the callback is called again (or during cleanup).
See-also: https://curl.haxx.se/libcurl/c/CURLMOPT_TIMERFUNCTION.html
glib really likes the numeric source IDs. That is, g_idle_add(), g_timeout_add(),
etc. return those IDs, that can then be destroyed with g_remove_source() (or
nm_clear_g_source()).
I think these numeric IDs are really not great.
- API like g_idle_add() and g_remove_source() only works with the g_main_context_get_default()
instance. That means, you cannot use this API for any other contexts. If you'd insist on using
numeric IDs, you'd need to call g_main_context_find_source_by_id() on the right context
first (but you'd also have to track the context alongside the ID).
- g_remove_source() requires first a call to g_main_context_find_source_by_id(). This involves
taking a mutex and doing an extra hash lookup.
Instead, it often seems preferable to use the GSource instance directly. It works
with any context, it can be referenced and unreferenced, and it can be destroyed, and
avoids the overhead of g_main_context_find_source_by_id().
The only downside really is that keeping a GSource pointer takes one pointer size, while
the guint source ID is usually only 4 bytes.
Anyway, I think we should deal more with GSource instances directly. Hence, add this
convenience macro, that works like nm_clear_g_source().
For the moment, we use docker images from dockerhub, which require
a lot of extra overhead to prepare and install the test environment.
This should be improved, by using more suitable container images.
Anyway, for now to alleviate the pressure on the freedesktop gitlab
infrastructure, disable most test to only run manually.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/241#note_282521
svUnsetValue (ifcfg, KEY);
if (condition)
svSetValue* (ifcfg, KEY, ...);
is not good. It requires first clearing the value, before setting
it again.
Various cleanup to fix such uses.
In some cases it is useful to have the library log what it is doing
for debugging purposes; add a simple API that allows setting a
syslog-style logging level and specifying a logging function.
https://github.com/nettools/n-dhcp4/pull/8
Deprecate the 'Carrier' property present in some Device sub-interfaces
in favor of the 'Carrier' flag in the InterfaceFlags property, which
is more general as it is available for all interfaces.
Add a new 'carrier' flag to the InterfaceFlags property of devices to
indicate the current carrier state.
The new flag is equivalent to the 'lower-up' flag for all devices
except the ones that use a non-standard carrier detection mechanism
like NMDeviceAdsl.
Add a new read-only "InterfaceFlags" property to the Device interface
to export via D-Bus kernel flags and possibly other NM specific
flags. At the moment IFF_UP and IFF_LOWERUP are implemented.
After we set link parameters (auto-negotiation, speed, duplex) in
stage1, the carrier can go down for several seconds because the
Ethernet PHY needs to renegotiate the link. Wait that carrier goes up
before starting the supplicant or the EAPoL start packet can be lost
causing an authentication failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1759797
[user] are arbitrary strings that can be attached to a connection.
NetworkManager itself does not care about them, they are only here
for other applications.
Allow reapplying changes to the user setting. Usually the reason to
reject reapplying a setting is because it's either not implemented
or not possible to change (without a full reactivation of the device).
In this case there is nothing to implement, and of course it's possible
to do so.
Currently in any of the BOUND, RENEWING and REBINDING states the probe
checks the expiration of T1, T2 and lifetime. This is not correct
because, for example, if the timer fires in the RENEWING state, the
probe must not transition to RENEWING again (i.e. check again that
now >= T1). Note that there is no guarantee that the timer triggers
exactly once for T1, T2 and lifetime expirations because the timer is
also used for the retransmission logic in NDhcp4CConnection.
Therefore, add some checks to ensure that only correct transitions are
allowed.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/341https://bugzilla.redhat.com/show_bug.cgi?id=1773456
