Include the circular, doubly-linked list implementation from
c-util/c-list [1], commit 864051de6e7e1c93c782064fbe3a86b4c17ac466.
[1] https://github.com/c-util/c-list
The user data values are encoded in shell variables named
prefix "NM_USER_". The variable name is an encoded form of the
data key, consisting only of upper-case letters, digits, and underscore.
The alternative would be something like
NM_USER_1_KEY=my.keys.1
NM_USER_1_VAL='some value'
NM_USER_2_KEY=my.other.KEY.42
NM_USER_2_VAL='other value'
contary to
NM_USER_MY__KEYS__1='some value'
NM_USER_MY__OTHER___K_E_Y__42='other value'
The advantage of the former, numbered scheme is that it may be easier to
find the key of a user-data entry. With the current implementation, the
shell script would have to decode the key, like the ifcfg-rh plugin
does.
However, user data keys are opaque identifers for values. Usually, you
are not concerned with a certain name of the key, you already know it.
Hence, you don't need to write a shell script to decode the key name,
instead, you can use it directly:
if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then
do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42"
fi
Otherwise, you'd first have to search write a shell script to search
for the interesting key -- in this example "$NM_USER_2_KEY", before being
able to access the value "$NM_USER_2_VAL".
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons
instances. Users of those are for example NMDevice, which registers
to GObject signals of both NMPlatform and NMRouteManager.
Hence, as NMDevice:dispose() disconnects the signal handlers, it must
ensure that those singleton instances live longer then the NMDevice
instance. That is usually accomplished by having users of singleton
instances own a reference to those instances.
For NMDevice that effectively means that it shall own a reference to
several singletons.
NMPlatform, NMRouteManager, and NMDefaultRouteManager are all
per-namespace. In general it doesn't make sense to have more then
one instances of these per name space. Nnote that currently we don't
support multiple namespaces yet. If we will ever support multiple
namespaces, then a NMDevice would have a reference to all of these
manager instances. Hence, introduce a new class NMNetns which bundles
them together.
nmcli has documentation strings embedded. Those strings are extracted
from gtk-doc comments, using pygobject and put in the generated file
"clients/common/settings-docs.c".
This file "clients/common/settings-docs.c" is disted, so from
a source tarball you can build nmcli without enabling introspection.
However, when building from a git-tree, the file is missing and
thus one cannot build --with-nmcli unless also using at least
--enable-introspection to generate "clients/common/settings-docs.c".
That is inconvenient. Especially during cross-compilation, where
one also needs python and pygobject in the foreign architecture (because
the generation of "settings-docs.c" loads the built libnm.so via
pygobject). It is bad because nmcli is an essential part of
NetworkManager, so building --without-nmcli is not a great option.
Previously, the only alternative was to pre-generate a source tarball
on a separate machine and build that. This however complicates efforts
to automatically build git snapshots of NetworkManager.
Fix that by commiting "clients/common/settings-docs.c.in" to git.
When building with --disable-introspection, the pre-generated
file is used instead. This is fine, because the file only depends
on static, checked-in documentation strings that seldomly change.
Also add a check target to notice when the pre-generated file differs
from what we are about to generate during --enable-introspection.
That happens when editing one of the gtk-doc entires. In this case,
`make check` will notify that the pre-generated "settings-docs.c.in"
file needs updating too.
Yes, when changing gtk-doc comments you need to updte the file manually.
At least, the check failure notifies you.
"nm-meta-setting-desc.h" contains static type description, vtable and (internal)
accessor functions. Add accessor functions that operate on top of the type description
to "nm-meta-setting-access.h".
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
These functions are only used by nm-meta-setting-desc.c. Make them internal.
Unfortunately, they are part of "common.h" which cannot be used without
the rest of nmcli. Still todo.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
This moves tracking of connectivity to NMDevice and makes the NMManager
negotiate the best of known connectivity states of devices. The NMConnectivity
singleton handles its own configuration and scheduling of the permission
checks, but otherwise greatly simplifies it.
This will be useful to determine correct metrics for multiple default routes
depending on actual internet connectivity.
The per-device connection checks is not yet exposed on the D-Bus, since they
probably should be per-address-family as well.
Works by dumb luck for in-tree build, because the .deps files that are
meant for the distribution happen to be the builddir. The out-of-tree
builds would generate an empty file.
We also dist libnm/nm-property-docs.xml, so depending on
whether we build from git or source tarball, the file
is in $(srcdir) or $(builddir).
Fixes: d7ad13591b
There are very few places where we actually use floating point
or #include <math.h>.
Drop that library, although we very likely still get it as indirect
dependency (e.g. on my system it is still dragged in by libsystemd.so,
libudev.so and libnl-3.so).
One day, I wish we would have more setting metadata in shared via
"shared/nm-setting-metadata.h", ready for nmcli and nmtui to use
(by statically linking against the internal API).
Anyway, it is still unused, so drop the files from the SOURCES of
nmcli.
"$(srcdir)/clients/cli/settings.c" includes "$(builddir)/clients/cli/settings-docs.c",
hence, we need "-I$(builddir)/clients/cli".
This basically reverts commit bbce089840,
but adds dependencies so that the build directory exists.
The sources should reach files in the $builddir using #include "".
Besides, it is not guarranteed to be around:
CC shared/clients_cli_nmcli-nm-setting-metadata.o
cc1: error: ./clients/cli: No such file or directory [-Werror=missing-include-dirs]
cc1: all warnings being treated as errors
Makefile:12971: recipe for target 'shared/clients_cli_nmcli-nm-setting-metadata.o' failed
It's not sufficient to make nm-core-enum-types.[ch] depend on the
dirstamp, because they also depend on their own stamps that are to be
placed in libnm-core.
$ make libnm-core/nm-core-enum-types.h.stamp
GEN libnm-core/nm-core-enum-types.h
/bin/sh: libnm-core/nm-core-enum-types.h.tmp: No such file or directory
../../Makefile.glib:107: recipe for target 'libnm-core/nm-core-enum-types.h.stamp' failed
make: *** [libnm-core/nm-core-enum-types.h.stamp] Error 1
We use output redirection in numerous places; leaving the half-built
artifacts in place would cause the subsequent builds to succeed when it
should not.
The only reliable way of setting a MAC address for the team is through
the "hwaddr" property in the configuration passed to teamd. In order
to rewrite the configuration we need Jansson support; since it is
already a requirement for teamd, let the team plugin depend on it.
If configure is called without --enable-json-validation or
--disable-json-validation, let's automatically choose a value
depending on the availability of the library.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
Since we generate "libnm-core/nm-core-enum-types.h" via GLIB_GENERAED,
there is no obvious place to $(MKDIR_P). Add a dependency to the
.dirstamp of the directory to instruct automake to create the directory.
