Commit graph

5 commits

Author SHA1 Message Date
Wen Liang
6b50d52ed0
docs: improve manual page about ipv4.routes
Signed-off-by: Wen Liang <liangwen12year@gmail.com>

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/757
2021-02-23 22:04:16 +01:00
Thomas Haller
9e7af31454
bond: avoid logging warning to set "ad_actor_system=00:00:00:00:00:00"
The bond option ad_actor_system only matters (and is available) with
mode=802.3ad.

When you create a new bond, the sysctl value will be set to "00:00:00:00:00:00".
So this seems to be a valid value, and in fact the default value for
this option. However, kernel will fail with EINVAL to set the sysctl to
"00:00:00:00:00:00". Kernel fails both if the value is already
"00:00:00:00:00:00" (i.e. setting the same value results in an error) and
it also fails otherwise (i.e. we cannot ever reset the value to
"00:00:00:00:00:00", at least not via sysfs).

Avoid the warning in the common case, where the value is already as
expected.

Otherwise, we still get the warning and won't be able to set the right
value. But this is really a limitation of the kernel API where we cannot
do anything about it (in NetworkManager).

https://bugzilla.redhat.com/show_bug.cgi?id=1923999
2021-02-23 14:18:02 +01:00
Thomas Haller
341b6e0704
all: change G_LOG_DOMAIN to "nm"
glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.

However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.

Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.

Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.

It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?

Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.

See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
2021-02-18 19:46:57 +01:00
Thomas Haller
243051a8a6
libnm/build: always compile both crypto backends if library available
We want to see that both backends can actually compile -- at least,
if we have the dependencies detected.
2021-02-18 19:46:54 +01:00
Thomas Haller
fdf9614ba7
build: move "libnm-core/" to "src/" and split it
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.

Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.

Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.

The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
2021-02-18 19:46:51 +01:00