When a VPN plugin logs to syslog(), it should not use the syslog
levels that were passed in by NetworkManager directly. Instead,
it must map LOG_NOTICE to LOG_INFO and LOG_INFO to LOG_DEBUG.
Add a utility function does gets that right.
- reorder entries in src/Makefile.am so that general names
are all at the beginning (AM_CPPFLAGS, sbin_PROGRAMS)
and the names for a certain library/binary are grouped
together
- have libNetworkManager.la reuse libNetworkManagerBase.la.
- let all components in src/Makefile.am use the same AM_CPPFLAGS,
except libsystem-nm.la.
- move callouts/nm-dispatcher-api.h to shared/ directory. It
is obviously not internal API to callouts, and callouts is
not a library. Thus, the right place is shared/.
Soon we will add proxy support where VPN plugins set a property
NM_VPN_PLUGIN_CONFIG_PROXY_PAC.
All a VPN plugin needs to make use of this new setting is the
NM_VPN_PLUGIN_CONFIG_PROXY_PAC define.
We don't want that older plugins (still compatible with libnm 1.2 API)
require a new API only for this define. Define it instead in
"shared/nm-utils/nm-vpn-plugin-macros.h" as fallback.
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00154.html
When using g_return_val_if_reached(), the default macro would include
the function name. This name is increasing the binary size. Replace
it in non-debug builds.
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
We use statement expressions all over the place without explicitly
marking them. If that would be a problem, we'd have to change a
*lot* of code. We simply require that as a mandatory feature from
our compiler.
"nm-glib.h" is the most basic header, the one we cannot do without.
("nm-default.h", is already more generic, the one which every common
source file in NetworkManager repository should include).
Let "gsystem-local-alloc.h" be included by "nm-glib.h" and nowhere
else.
This file is only used by plugins and copied between them.
It's purpose is to contain general utility functions that are
only relevant for implementing NetworkManager's VPN plugins.
In principle the utility functions could be part of libnm, however,
there are a few problems with that:
- if they are part of libnm, adding and using a new utility function
requires the plugin to bump the required libnm version. Since you
usally can work around/reimplement utility functions, this results
in not using the API from libnm, not adding the API to libnm,
and reimplementing it over and over in the plugin.
- plugins compile both against libnm and libnm-glib. Thus, either
the utility function would also be needed in libnm-glib, or again,
it is not usable by the plugin.
We must avoid that the utility functions diverge and no local
modifications to these files should be made in the plugin.
Instead, one special location of the utility functions shall be
extended and re-imported (copied) to the plugin as needed.
Add the files to NetworkManager's repository. Although they are not
needed for NetworkManager itself, they are a different API provided
by NetworkManager. An API that is reused and shared by copying the files
around.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.
The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.
Assertions like g_assert*() and g_return_*() contain the stringified
test expression. This string ends up in the binary and increases its
size.
We usually don't have failing assertions. These string are a waste,
instead the file and line number shall suffice.
It reduces the striped size of the NetworkManager binary from 2500k
to 2392k, that is -108k, -4.3%.
This changes
- "g_assert (1 == 2);"
from: NetworkManager:ERROR:source.c:347:some_function: assertion failed: (1 == 2)
to: NetworkManager:ERROR:source.c:347:<unknown-fcn>: assertion failed: (<dropped>)
- "g_return_if_fail (1 == 2);"
from: (process:21024): NetworkManager-CRITICAL **: some_function: assertion '1 == 2' failed
to: (process:21024): NetworkManager-CRITICAL **: ((source.c:347)): assertion '<dropped>' failed
When doing a non-debug build, those string are now removed. Debug-builds
can be enabled by setting --with-more-assert=$LEVEL to larger then zero.
https://bugzilla.gnome.org/show_bug.cgi?id=767296
A failure to g_return*() by default prints a g_critical() with stringifing the
condition. Add a macro NMTST_G_RETURN_MSG() that reproduces that line to more
accurately match the failure message.
Shared headers are all project-wide and internal API.
Currently we have the following:
General purpose:
- shared/gsystem-local-alloc.h: header-only, allocation macros
- shared/nm-dbus-compat.h: header-only, D-Bus related defines
- shared/nm-glib.h: header-only, glib compatibility defines
- shared/nm-macros-internal.h: header-only, utils
- shared/nm-shared-utils.[hc]: source and header, utils
- shared/nm-test*.[hc]: source and header, libnm testing utils
Special to NetworkManager repository:
- shared/nm-version-macros.h.in: header-only, version macros
- shared/nm-default.h: header-only, default-include
Now we add "shared/nm-common-macros.h" which is header-only, but non
general purpose.
I am running low on good names, considering all the shared/core/macros
utils headers. Still, I think "nm-common-macros.h" is appropriate.
A large part of "nm-test-utils.h" is only relevant for tests inside "src/"
directory, as they are helpers related to NetworkManager core part.
Split this part out of "nm-test-utils.h" header.
In NetworkManager's configure script we have --with-more-asserts
option which always defines NM_MORE_ASSERTS in config.h.
When reusing the header file outside of NetworkManager, the
NM_MORE_ASSERTS define might be unset. Define it in that case
to avoid compiler warnings about undefined preprocessor define.
To allow for trailing whitespace, we don't need to copy and trunacate
the input string. g_ascii_strtoll() conveniently returns the location via
the endptr argument.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
