GCC can place each symbols into separate sections making it possible for
ld to discard unneeded sections (and thus symbols afterwards). This achieves
almost the same size benefits as LTO without the huge performance
penalty (and the undefined behavior with -g).
The cost of more section headers in .o files seems to be negligible.
Before:
359.73user 71.94system 1:29.67elapsed 481%CPU (0avgtext+0avgdata 137948maxresident)k
text data bss dec hex filename
2772228 74848 9272 2856348 2b959c src/NetworkManager
With LTO:
740.37user 94.89system 4:13.83elapsed 329%CPU (0avgtext+0avgdata 118316maxresident)k
text data bss dec hex filename
2435437 74224 8704 2518365 266d5d src/NetworkManager
With --gc-sections:
365.63user 72.34system 1:30.12elapsed 485%CPU (0avgtext+0avgdata 138016maxresident)k
text data bss dec hex filename
2498498 74040 8408 2580946 2761d2 src/NetworkManager
This way it's consistently used across all manual page without a need
for XSL templating.
Also, the entities file could in future possibly be used to template the
build-time configurables such as filesystem paths or bug tracker URL.
It should really be in /usr/lib, not /lib. Not a real issue, since the two are
usually links, but the latter is supposably for compatibility only. This also
installs into correct place when configured with a different --prefix.
Choose a new logging format.
- the logging format must not be configurable and it must be the
same for all backends. It is neat that journal supports additional
fields, but an average user still posts the output of plain
journalctl, without "--output verbose" (which would also be hard
to read).
Also, we get used to a certain logging format, so having different
formats is confusing. If one format is better then another, it should
be used for all backends: syslog, journal and debug.
The only question is, what is the best format.
- the timestamp: I find it useful to see how much time between two
events passed. The timestamp printed by syslog doesn't have sufficient
granularity, and the internal journal fields are not readily available.
We used to print the timestamps for <error>, <debug> and <trace>,
but ommited them for <info> and <warn> levels. We now print them for
all levels, which has a uniform alignment.
- the location: the "[file:line] func():" part is mostly redundant
and results in wide lines. It also causes a misalignment of the
logging lines, or -- as I recently added alignment of the location --
it results in awkward whitespace and truncation.
But the location is really just necessary because our logging messages
are bad:
"<debug> [1456397604.038226] (9) 11-dhclient succeeded"
The solution to this is not
"<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded"
but a properly worded message:
"<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded"
- logging-message: we need to write better logging messages.
I like some form of "tags" that are easy to grep:
"platform: signal: link changed: 4: ..."
Downside is, that this is not nice to read as a full sentence.
So, especially for <info> and <warn> logging, more human readable
messages are better.
We should find a compromise, where the log message explains what
happens, but is still concise and contains patterns that are easy
to grep and identify visually.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html
Sorry, it was not Debian's fault. It is only libnss-devel package on
Ubuntu 12.04/Precise [1].
Revert the workaround and avoid the failure by dropping the version check altogether.
NSS 3.11 is from 2006, it's unlikely a user tries to build current NetworkManager
against such an old version of the library.
[1] https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1547147
This reverts commit d48790cbec.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
These initscripts weren't modified for a long time. Are they just
unused or flawless? It seems they are no longer best-practice
(e.g. NetworkManager supports reloading configuration via SIGHUP,
which none of these scripts implement).
Nowadays some distributions moved to systemd and quite possible
nobody uses these scripts. Also, any potential downstream user
probably has an adjusted copy of them in their repositories.
Just remove them.
https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00003.html
Can't just substitute sysconfdir into a header file -- it's meant to be
expanded in a Makefile. Otherwise, unexpanded ${prefix} will end up in a
header file.
We do that for NMCONFDIR already, let's use it here too.
Fixes: 2144457fab
When you want to run valgrind for a test, you either had to
invoke valgrind manually, or doing it via `make check` (provided
you configured --with-valgrind).
Make it more convenient to run valgrind by passing the test
to run to the "run-test-valgrind.sh" wrapper.
This also allows to pass -p/-s to the test, which is not possible
during `make check` because selecting tests conflicts with "--tap".
The following invocations are largely equivalent and work as
expected:
$ ./tools/run-test-valgrind.sh ./src/platform/tests/test-link-linux -p /link/software/detect/vlan
$ NMTST_DEBUG=no-debug,p=/link/software/detect/vlan ./tools/run-test-valgrind.sh ./src/platform/tests/test-link-linux
Instead of using libnl-route-3 library to serialize netlink messages,
construct the netlink messages ourselves.
This has several advantages:
- Creating the netlink message ourself is actually more straight
forward then having an intermediate layer between NM and the kernel.
Now it is immediately clear, how a platform request translates to
a netlink/kernel request.
You can look at the kernel sources how a certain netlink attribute
behaves, and then it's immediately clear how to set that (and vice
versa).
- Older libnl versions might have bugs or missing features for which
we needed to workaround (often by offering a reduced/broken/untested
functionality). Now we can get rid or workaround like _nl_has_capability(),
check_support_libnl_extended_ifa_flags(), HAVE_LIBNL_INET6_TOKEN.
Another example is a libnl bug when setting vlan ingress map which
isn't even yet fixed in libnl upstream.
- We no longer need libnl-route-3 at all and can drop that runtime
requirement, saving some 400k.
Constructing the messages ourselves also gives better performance
because we don't have to create the intermediate libnl object.
- In the future we will add more link-type support which is easier
to support by basing directly on the plain kernel/netlink API,
instead of requiring also libnl3 to expose this functionality.
E.g. adding macvtap support: we already parsed macvtap properties
ourselves because of missing libnl support. To *add* macvtap
support, we also would have to do it ourself (or extend libnl).
Constructing the libnl3 object only to parse the message
is wasteful. It involves several memory allocations, thread
synchronization and parsing fields that we don't care about.
But moreover, older libnl version might not support all the
fields we are interested in, hence we have workarounds like
_nl_link_parse_info_data(). Certain features might not fully
work unless libnl supports it too (although kernel would).
As we already parse the data ourselves sometimes, just go
all they way and don't construct the intermediate libnl object.
This will allow us to drop the _nl_link_parse_info_data() workarounds
in next commits. That is important, because _nl_link_parse_info_data()
sidesteps our platform cache and is not in sync with the cache (not to
mention the extra work to explicitly refetch the data on every lookup).
Also, it gets us 60% on the way to no longer needing 'libnl-route-3.so'
at all and eventually drop requiring the library.
Allows to enable more-asserts more granularly.
Unfortunately, the old check was "${enable_more_asserts} == "yes", thus
we cannot extend "--enable-more-assert=level" because that would mean
that the same build script cannot set the option on both old and new
NetworkManager.
Thus, add a new option --with-more-asserts=level. If you put the
following in your build script, it will work as expected whether
you build a new or an old version of NetworkManager.
./configure --enable-more-asserts --with-more-asserts=5
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
NetworkManager set wpa_supplicant's fragment_size option to 1300. But if MTU
was lower, wpa_supplicant failed with "l2_packet_send - sendto: Message too
long" due to fragmentation of EAP-TLS or EAP-PEAP packets.
Actually, MTU has to be 14 bytes bigger than the "fragment_size" parameter.
Ideally, wpa_supplicant would take MTU in the account and adjust the
fragmentation limit accordingly. See discussion in
http://lists.shmoo.com/pipermail/hostap/2015-August/033546.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=755145
GNOME release tooling repacks the bz2 to a xz anyway. This makes it easier for
packagers to use tarballs created with "make dist" in place of distribution
tarballs.
Add --without-libnm-glib, for people who don't want to build the
legacy client libraries. When building with this option, dbus-glib and
libdbus are not required.
Port remaining bits to gdbus and remove stray dbus-glib references
Drop the dbus-glib version check from configure, since nothing depends
on new dbus-glib any more.
Move nm-dbus-glib-types.h and nm-gvaluearray-compat.h from include/ to
libnm-util/ since they are now only used by libnm-util and libnm-glib.
