c-stdaux is C11 and so is NetworkManager too.
But we build on Ubunut 14.04, where we have not all C11 parts
in place.
Since the header is not actually used (at the moment), patch out
the include.
Instead of growing the buffer for the tokens (and reallocating),
do one pre-run over the string and count the delimiters. This
way we know how much space we need and we don't need to
reallocate.
Interestingly, this is notably slower than the previous implementation,
because previously if would not bother determining the right number of
tokens but just over-allocate with a reasonable guess of 8 and grow the
buffer exponentially. Still, I like this better because while it may
be slower in common scenarios, it allocates the exact number of buffer
space.
Previously, nm_utils_strsplit_set_full() would always remove empty
tokens. Add a flag NM_UTILS_STRSPLIT_SET_FLAGS_PRESERVE_EMPTY to avoid
that.
This makes nm_utils_strsplit_set_full() return the same result as
g_strsplit_set() and a direct replacement for it -- except for "",
where we return %NULL.
Drop the next_char() and is_delimiter() macros. They are difficult to
understand, because they both have a state-variable (escaped).
Instead, the state of whether we handle an escape or not, shall only
depend on the current line of code.
The caller should make a conscious decision which delimiters to use.
Unfortunately, there is a variety of different demiters in use. This
should be unitfied and the callers should use one of a few specific
set of delimiters.
This could be unified by (re)using a define as delimiters, like
strv = nm_utils_strsplit_set_full (value, MULTILIST_WITH_ESCAPE_CHARS, NM_UTILS_STRSPLIT_SET_FLAGS_ALLOW_ESCAPING);
where MULTILIST_WITH_ESCAPE_CHARS has a particular meaning that should
be reused for similar uses.
However, leaving the delimiter at NULL is not good because it's unclear who
wants that default behavior (and what the default should be). Don't allow that.
There are almost no callers that relied on this default anyway.
Traditionally, the MTU in "datagram" transport mode was restricted to
2044. That is no longer the case, relax that.
In fact, choose a very large maximum and don't differenciate between
"connected" mode (they now both use now 65520). This is only the
limitation of the connection profile. Whether setting such large MTUs
actually works must be determined when activating the profile.
Initscripts "ifup-ib" from rdma-core package originally had a limit of 2044.
This was raised to 4092 in rh#1186498. It is suggested to raise it further
in bug rh#1647541.
In general, kernel often does not allow setting large MTUs. And even if it
allows it, it may not work because it also requires the entire network to
be configured accordingly. But that means, it is generally not helpful to
limit the MTU in the connection profile too strictly. Just allow large
MTUs, we need to see at activation time whether the configuration works.
Note also that all other setting types don't validate the range for MTU at
all.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1186498
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1593334
(rdma-core: raise limit from 2044 to 4092 in ifup-ib)
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1647541
(rdma-core: raise limit beyond 4092 in ifup-ib)
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1532638#c4
(rdma-core: MTU related discussion)
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534869
(NetworkManager bug about this topic, but with lots of unrelated
discussion. See in particular #c16)
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1653494
Previously, this would re-implement what nm_strstrip_avoid_copy()
was doing.
Use nm_strstrip_avoid_copy_a() instead, which avoids the code
duplication and the heap allocation in common cases.
The main difference between "shared/nm-utils/nm-macros-internal.h" and
"shared/nm-utils/nm-shared-utils.h" is that the former is header-only
while the latter has a source file as well.
Apart from that, both headers are included everywhere.
The next commit will add nm_strstrip_avoid_copy_a() to
"nm-macros-internal.h" header, which will use nm_strndup_a().
Hence, also nm_strndup_a() should be in "nm-macros-internal.h".
"_str" is a very tempting name for a temporary variable.
Rename the variable in nm_strndup_a() macro, so that other macros can
call these (more general) macros (and still use the name "_str").
If we don't have explicit_bzero(), try a bit harder and use
a volatile pointer.
This is also what libsecret's egg_secure_clear() does [1]. However, for
us this is less important, because commonly we expect glibc to provide
a useable explicit_bzero().
[1] b5442654d4/egg/egg-secure-memory.c (L1352)
Add NMIPRoutingRule API with a few basic rule properties. More
properties will be added later as we want to support them.
Also, add to/from functions for string/GVariant representations.
These will be needed to persist/load/exchange rules.
The to-string format follows the `ip rule add` syntax, with the aim
to be partially compatible. Full compatibility is not possible though,
for various reasons (see code comment).
It's usually not necessary, because _nm_utils_unescape_spaces()
gets called after nm_utils_strsplit_set(), which already removes
the non-escaped spaces.
Still, for completeness, this should be here. Also, because with
this the function is useful for individual options (not delimiter
separate list values), to support automatically dropping leading or
trailing whitespace, but also support escaping them.
Part 1, which addresses the issue for simple properties that have
a plain remove-by-value function.
Rationale:
Removing a value/index that does not exist should not be a failure.
Woule you like:
$ nmcli connection modify "$PROFILE" autoconnect no
$ nmcli connection modify "$PROFILE" autoconnect no
Error: autoconnect is already disabled
So, why would it be a good idea to fail during
$ nmcli connection modify "$PROFILE" -vpn.data ca
$ nmcli connection modify "$PROFILE" -vpn.data ca
Error: failed to remove a value from vpn.data: invalid option 'ca'.
Generally, it should not be an error to remove an option, as long
as the option itself is valid. For example,
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map bogus
should fail, but
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map 1:5
should succeed even if there was nothing to remove.
The same code is used by nmcli. Obviously, clients also need to
parse string representations.
That begs the question whether this should be public API of libnm.
Maybe, but don't decide that now, just reuse the code internally via
"shared/nm-libnm-core-utils.h".
We have code in "shared/nm-utils" which are general purpose
helpers, independent of "libnm", "libnm-core", "clients" and "src".
We have shared code like "shared/nm-ethtool-utils.h" and
"shared/nm-meta-setting.h", which is statically linked, shared
code that contains libnm related helpers. But these helpers already
have a specific use (e.g. they are related to ethtool or NMSetting
metadata).
Add a general purpose helper that:
- depends (and extends) libnm-core
- contains unrelated helpers
- can be shared (meaning it will be statically linked).
- this code can be used by any library user of "libnm.so"
(nmcli, nm-applet) and by "libnm-core" itself. Thus, "src/"
and "libnm/" may also use this code indirectly, via "libnm-core/".
nm_utils_parse_inaddr() is trivial enough to reimplement it, instead of calling
nm_utils_parse_inaddr_bin(). Calling nm_utils_parse_inaddr_bin() involves several
things that don't matter for nm_utils_parse_inaddr() -- like assigning
out_addr_family or returning the binary address.
This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
On Fedora rawhide we get the following build failure:
In file included from shared/systemd/src/basic/alloc-util.c:3:
./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:114:21: error: static declaration of 'gettid' follows non-static declaration
114 | static inline pid_t gettid(void) {
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from /usr/include/glib-2.0/gio/gcredentials.h:32,
from /usr/include/glib-2.0/gio/gio.h:46,
from ./shared/nm-utils/nm-macros-internal.h:31,
from ./shared/nm-default.h:293,
from ./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:22,
from shared/systemd/src/basic/alloc-util.c:3:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
glibc supports now gettid() call ([1]) which conflicts with our compat
implementation. Rename it.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1d0fc213824eaa2a8f8c4385daaa698ee8fb7c92
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
