Note that:
- we compile some source files multiple times. Most notably those
under "shared/".
- we include a default header "shared/nm-default.h" in every source
file. This header is supposed to setup a common environment by defining
and including parts that are commonly used. As we always include the
same header, the header must behave differently depending
one whether the compilation is for libnm-core, NetworkManager or
libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h>
depending on whether we compile a library or an application.
For that, the source files need the NETWORKMANAGER_COMPILATION #define
to behave accordingly.
Extend the define to be composed of flags. These flags are all named
NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the
build are available. E.g. when building libnm-core.la itself, then
WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE
are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE
is not available but the internal parts are still accessible. When
building nmcli, only WITH_LIBNM_CORE (the public part) is available.
This granularily controls the build.
The logging macros already prepend a "config: " prefix. Don't
repeat that in the message, otherwise we get
config: config: signal SIGHUP (no changes from disk)
Now:
config: signal: SIGHUP (no changes from disk)
The internal client asserts that the length of the client ID is not more
than MAX_CLIENT_ID_LEN. Avoid that assert by truncating the string.
Also add new nm_dhcp_client_set_client_id_*() setters, that either
set the ID based on a string (in our common dhclient specific
format), or based on the binary data (as obtained from systemd client).
Also, add checks and assertions that the client ID which is
set via nm_dhcp_client_set_client_id() is always of length
of at least 2 (as required by rfc2132, section-9.14).
NMDhcpManager used a hash table to keep track of the dhcp client
instances. It never actually did a lookup of the client, the only
place where we search for an existing NMDhcpClient instance is
get_client_for_ifindex(), which just iterated over all clients.
Use a CList instead.
The only thing that one might consider a downside is that now
NMDhcpClient is aware of whether it is part of a list. Previously,
one could theoretically track a NMDhcpClient instance in multiple
NMDhcpManager instances. But that doesn't make sense, because
NMDhcpManager is a singleton. Even if we would have mulitple NMDhcpManager
instances, one client would still only be tracked by one manager.
This tighter coupling of NMDhcpClient and NMDhcpManager isn't
a problem.
This is still the very same approach (in the way the array is split
and how elements are compared). The only difference is that the
recursive implementation is replaced by a non-recursive one.
It's (still) stable, top-down merge-sort.
The non-recursive implementation better, because it avoids the overhead
of the function call to recurse.
We don't have a complete list of distributions that use ifcfg for network
configuration but we can easily check for `/etc/sysconfig/network-scripts`
and then distributions can explicitly disable the plugin of that is what
they want.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
In future we should probably either switch to `/etc/os-release` or just
check for `/etc/sysconfig` or something like that.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
It is slightly less obsolete. We don't really support precise (12.04)
anyway, the build only works because we steal libndp and perhaps more
from the trusty repository.
gtkdoc uses some custom generated targets as content files. However,
there are still two problem. The first is that gtkdoc does not
support targets which are not strings. This is being fixed in the
following issue:
https://github.com/mesonbuild/meson/pull/2806
The second issue is that the gtkdoc function produces a target which
is triggered at install time. This makes the dependencies generation
to not be triggered.
This patch uses a workaround for that second issue.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00079.html
Instead, intern the string and cache it in the NMDeviceClass instance.
It anyway depends entirely on the GObject type (name), hence it should
also be cached at the type.
nm_match_spec_device_by_pllink() does not support matching on all parameters,
unlike nm_match_spec_device(). The reason is that certain parameters are
only available when having a NMDevice instance.
Add an argument "match_device_type", so that the caller can inject the
device type to be used. Note that for NMDevice, the device-type is
nm_device_get_type_description(), which usually depends on the device
class only. The only caller of nm_match_spec_device_by_pllink() is the
wifi factory, and it already knows that it wants to create a device of
type NMDeviceWifi. Hence, it knows and can specify "wifi" as
match_device_type.
... by platform link.
One caveat is that without having a NMDevice instance, matching by
several paramters won't work. Like, matching against the driver would
require us to look it up via ethtool. When having an NMDevice instance,
the driver is cached there, it's unclear we want to call ethtool for
lookup in this case -- though it could be done.
For other options, it's more complicated. Like, the type basically
depends on the NMDevice class. Usually that also works without a
netdev known to kernel (like bluetooth).
The inconsistency that certain matches are not implemented is ugly
indeed. But the effect is as if the spec doesn't match.
Add a variant of nm_device_spec_match_list() that looks up the match
paramters from a platform link instance.
Usually, we have a NMDevice instance that we use for matching.
However, at some places (like inside the device factory's
create_device() method), we might not have a NMDevice instance
to get the match paramters.
Add an alternative form, that gets the match paramters from a platform
link instance.
The code is placed inside src/NetworkManagerUtils.c, because
src/nm-core-utils.c is supposed to be independent of platform.
There were no places where we actually looked up an instance
in the hash-table. All we did was iterating the list.
CList is faster with iterating, has less memory over-head (in this
particular case), and can also do O(1) insert and removal. It's
more suited in every way.
private_server_free() had only one caller: nm_bus_manager_private_server_register().
The only thing that nm_bus_manager_private_server_register() did in
addition was to check for duplicate server tags.
Merge the two functions.
Our convention is that when the body of an if() or for() spawns
more then one line, then it needs curly braces. If it's only one
line, it should have no curly braces. The latter part seems sometimes
a bit inconvenient, because changing
if (some_condition)
do_something ();
gets change to
if (some_condition) {
do_something ();
do_something_else ();
}
the diff shows 3 lines changed, although really only one changed.
But well, that's how it is...
Verify that an 8021x network is preprovisioned on IWD side before
declaring a connection as "available" or "compatible".
Also move the Infrastrucure mode check and the Hidden SSID check in
check_connection_available earlier because even if a compatible AP is
available and the connection can be used with wpa_supplicant, it can't
be used with IWD at this time.
This is mainly to enable using 8021x networks, which have to be
preprovisioned as an IWD config file to be supported and can not be
configured by asking the user for secrets over DBus, this is an IWD's
design choice.
Note that this assumes that secrets are only used during the Stage 2 of
the activation, i.e. for the wifi handshake, not in the later stages.
Keep a list of IWD's Known Networks which are networks that have their
configurations stored by IWD including the secrets, either because they
have been connected to before or because they were preprovisioned on the
machine.
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
The option is deprecated together with the ifcfg-suse settings plugin.
Selecting the plugin has no effect at runtime, beside logging a warning.
Drop the configure option.
Note, that if $distro_plugins was set to "ifcfg-suse", it was also used to
autodetect --with-hostname-persist=suse. Now, autodetect the hostname
persist mode based on presence of /etc/SuSE-release file.
