In file included from ./src/libnm-glib-aux/nm-default-glib.h:11:0,
from ./src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
from src/libnm-log-null/nm-logging-null.c:6:
./src/libnm-std-aux/nm-default-std.h:32:26: fatal error: config-extra.h: No such file or directory
#include "config-extra.h"
^
compilation terminated.
make[1]: *** [src/libnm-log-null/src_libnm_log_null_libnm_log_null_la-nm-logging-null.lo] Error 1
We should write our CONTRIBUTING files in markdown syntax, because
it's nice to read a plain text and gets nicely rendered.
However, if the file doesn't have a ".md" extension, gitlab's
web interface shows it as plain text file.
Rename the file.
This possibly breaks links like [1], but referring to a branch name
(and not a commit ID or a tag) is anyway fragile. Hence, I don't try
to fix that by adding a symlink or similar, because I think that just
makes it more confusing.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/CONTRIBUTING
CC src/libnm-platform/wifi/libnm_platform_la-nm-wifi-utils-wext.lo
In file included from ../src/libnm-platform/wifi/nm-wifi-utils-wext.c:7:
In file included from ../src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13:
In file included from ../src/libnm-glib-aux/nm-default-glib.h:11:
../src/libnm-std-aux/nm-default-std.h:30:10: fatal error: config-extra.h file not found
#include "config-extra.h"
^~~~~~~~~~~~~~~~
...
GEN config-extra.h
Note that "test-client.py" currently only tests nmcli. But what it does
is to spawn test-networkmanager-service.py and run nmcli against it.
As such, it could really be used to test any NetworkManager client
against the stub service. Hence this test is not under
"src/nmcli/tests", but under "src/tests/client/" where it is more
general.
Note that we take defines from "src/core/nm-config.h" which
are GPL-2.0-or-later licensed.
libnm-base we want to include in other LGPL licensed sources,
we it must also be LGPL.
"relicense" the code that I take. I don't think it's a problem, because:
- these are only plain defines. To which extend is that even
copyrightable?
- as far as I see, all the code was contributed by people who agreed
to such relicensing. See RELICENSE.md file.
Internally we set CPPFLAGS, because setting CFLAGS disables inheriting AM_CFLAGS --
which we use for example for "-Wno-pragmas" from the configure script.
"nm-compat.h" is not intended to be used by NetworkManager itself.
Instead, it's intended to be copied into the source tree of VPN plugins,
as adapter for different libnm versions.
Move it to "src/contrib/".
This file was intended to be used by VPN plugins (by copying it).
However, it was also used internally.
Split the file, and move the internally used part to libnm-glib-aux.
The part that is only there for out of tree users, moves to
"nm-compat.h".
This file is not actually to be used by NetworkManager itself.
Instead, every (glib based) VPN plugin will want something like this,
hence we have a copy here.
Move it to a new directory "src/contrib/".
This helper code is already used by several of our unit tests.
Compile it as a separate library.
Previously, the source code lingered unmotivated under "shared/",
which is confusing.
"nm-test-utils.h" is a header-only, helper library for our unit tests.
It was somewhat unmotivated in "shared/nm-utils", because all tests use
it, but it was not part of a "module".
Move it to "src/libnm-glib-aux/". It fits there very well. They both
have (only) a dependency on glib.
This is really just a different implementation of
"nm-glib-aux/nm-logging-fwd.h", that parallels libnm-log-core.
It's also not only useful to shared/systemd, but also share/nm-platform,
which also requires linking with a logging backend.
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
"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.
"nm-version-macros.h" is used directly by libnm-core and indirectly by
libnm and core.
Let's not have it randomly under shared/. Move it closer to where it's
used.
Before there was a licensing conflict between the keyfile code
(libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while
keyfile code was GPL-2.0+.
Consequently we were linking libnm-keyfile into the daemon, but not in
libnm.so.
This conflict has been resolved and keyfile API is part of libnm.so.
There is no more need to build a separate (intermediary) library. Merge
them.
This also makes sense because keyfile code needs access to private code
from libnm-core. It is closely tied to libnm-core, so that building them
separate makes no sense (anymore).
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
Our source tree also has certain consistency requirements. Since the
source is in git, this is a rather static check. However, we want to
ensure that future changes don't break it by adding a test.
autotools projects commonly should include "config.h" as first header.
Also, commonly we need more headers, like glib.h or our nm_auto macros.
Hence, almost all our sources should as first include "nm-default.h".
However, as we build different parts, "nm-default.h" gets controlled
by the NETWORKMANAGER_COMPILATION define which autotools/meson needs
to specify in the build options.
That is confusing.
One advantage of that was, that theoretically the same sources can
be built twice, with different behavior. However, we should avoid doing
that altogether and build static libraries (once) that we link multiple
times.
Another advantage was that if NETWORKMANAGER_COMPILATION is for example
set to build a DAEMON source, there is a check that we don't include
private headers from libnm-core. However, that should be better solved
by not having public, internal and private headers in the same
directory.
Instead, introduce different "nm-default-*.h" headers that don't require
special defines and behave in a consistent way. This way, we require
fewer CFLAGS and it's immediately clear by looking at the source alone
which headers are included. Also, you will be easier see when a wrong
nm-default-*.h header gets included.
Introduce the first replacement. The others will follow.
By now, keyfile code got relicensed as LGPL-2.1+ and is just a regular part
of libnm-core (in particular, because it uses private API of libnm-core).
It should no longer be in a separate directory, but for now, at lead compile
it the same as libnm-core.
We got rid of all these redundant defines. All we need, is the base
source directory, which we already define in config.h as
NM_BUILD_SRCDIR. Use that.
If you configure with "--enable-tests=no", then the tests
are not build during `make all`, but only during `make check`.
That is convenient for development, so if you don't work on tests,
they usually don't get build and the (partial) compilation is faster.
However, there is no target to build the tests without running them.
Add `make check-progs` for that.
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
This is basically all of libnm as a static-library. The name
liblibnm isn't great. Arguably, we do have quite a lot of
libnmxyz, so finding a good name is hard. But libnm-static seems
a better name. Rename.
Fix the following build error:
In file included from shared/nm-base/nm-ethtool-base.c:6:
./shared/nm-default.h:87:10: fatal error: config-extra.h: No such file or directory
87 | #include "config-extra.h"
| ^~~~~~~~~~~~~~~~
Fixes: e5d2a05ad5 ('libnm: add "shared/nm-base/nm-base.h"')
We want to use this by "shared/nm-platform", which should have
no dependency on "libnm-core".
Move "libnm-core/nm-ethtool-utils.h" to "libnm/nm-ethtool-utils.h" so
that it is only used by libnm. This file contains the defines for
the option names.
Also, symlink "libnm/nm-ethtool-utils.h" as "shared/nm-base/nm-ethtool-utils-base.h".
We want to use the same defines also internally. Since they are both
public API (must be in libnm) and should be in "shared/nm-base", this
is the way.
We want to use these defines for option names also in "shared/nm-base"
(and in turn in "shared/nm-platform), which cannot include "libnm-core".
However, they are also public API of libnm.
To get this done, in a first step, move these defines to a new header
"libnm-core/nm-ethtool-utils.h".
Since now the name "nm-ethtool-utils.h" is taken, also rename
nm-libnm-core-intern files.
Our dependencies are complicated.
Currently "src/platform" uses parts of libnm-core and is relatively
strongly entangled with core. It would be nice to have that part
clearly independent from "src" and from "libnm-core".
Also, "src/platform/nm-platform-utils.h" uses NMEthtoolID enum, which
previously was defined in "libnm-core/nm-libnm-core-intern/nm-ethtool-utils.h".
Move that to a new place "shared/nm-base/nm-base.h".
Note that we have "libnm-core/nm-libnm-core-intern", which is
libnm/core related code which uses and is used by libnm-core.
There is a need for a library which is used by libnm-core, but
does not depend on libnm-core itself. Here comes "shared/nm-base".
Yes, many libraries. But the goal is to entangle the dependencies
and have a clear hierarchy of includes. And to have "shared/nm-platform"
independent of libnm-core.
We want to move platform code to "shared/nm-platform". However, platform
code uses the logging infrastructure from the daemon, there is thus
an odd circular dependency.
Solve that by moving the "src/nm-logging.[hc]" to a new helper library
in "shared/nm-log-core".
NetworkManager core is huge. We should try to split out
parts that are independent.
Platform code is already mostly independent. But due to having it
under "src/", there is no strict separation/layering which determines
the parts that can work independently. So, while the code is mostly
independent (in practice), that is not obvious from looking at the
source tree. It thus still contributes to cognitive load.
Add a shared library "shared/nm-platform", which should have no
dependencies on libnm-core or NetworkManager core.
In a first step, move the netlink code there. More should follow.
Add a new key management option to support WPA3 Enteprise wifi
connection.
Only supported with wpa_supplicant for the time being.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
In C, includes with <> are for system headers, while "" prefers the
current working directory (implementation defined).
For libnm headers that include other libnm headers, we tend to use
"" instead of <>. That makes sense to me. Be consistent about that.
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
We can generate "generate-docs-nm-settings-nmcli.xml" by running "clients/cli/generate-docs-nm-settings-nmcli".
However, during cross compilation, that binary gets build in the target architecture,
it can thus not run to generate the XML.
Note that "--enable-gtk-doc" requires "--enable-introspection".
For generating "settings-docs.h" we (only) need introspection/pygobject.
We also have a pre-generated .in file that we can use if introspection
is not available. Since we have a pre-generated variant, it would be fine
to always use that one. However, we want to use generate the file if we
have the necessary dependencies, because thereby we can check whether
the pre-generated file is identical to what would be generated.
We have a similar problem with "generate-docs-nm-settings-nmcli.xml".
However there we don't need introspection, but merely being able to
execute a binary that we build. That does not work during cross
compilation, so we will honor "--enable-gtk-doc" flag to decide when
to generate the file.
For consistency, also adjust the condition for "settings-docs.h" to only
generate the file if we have "--enable-gtk-doc" (but not it we build
with "--enable-introspection" alone).
With glib2-2.67.0-1.fc34.x86_64.rpm, clang-11.0.0-2.fc34.x86_64.rpm, the
generated code emits a compiler warning:
libnm-core/tests/nm-core-tests-enum-types.c:17:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
libnm-core/tests/nm-core-tests-enum-types.c:40:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
libnm-core/tests/nm-core-tests-enum-types.c:63:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
We could pass "-Wincompatible-pointer-types-discards-qualifiers" as CFLAGS
when building this file. However, we have a workaround in our "nm-glib-aux/nm-glib.h",
so we can instead include "nm-default.h". At first glance, that might look like
the less preferable solution. However, this file is only there for unit tests,
and we also include "nm-default.h" for other sources that are generated with
"glib-mkenums". So, doing it also for our tests becomes the preferable solution.
NML3Cfg already handles IPv4 ACD. IPv4LL is just a small additional
layer on top of that, so it makes sense that it also is handled by
NML3Cfg.
Also, the overall goal is that multiple NMDevice and NMVpnConnection
instances can cooperate independently. So if multiple "users" enable
IPv4LL on an interface, then we should only run it once. This is
achieved by NML3IPv4LL's API where users register what they want,
and NML3IPv4LL figures out what that means as a whole.
Also, we thus will no longer need to use sd_ipv4ll/n-ipv4ll, because
we implement it ourself.
