This can be replaced by nm_utils_escaped_tokens_split().
Note that nm_utils_escaped_tokens_split() does not behave exactly
the same. For example, nm_utils_str_simpletokens_extract_next() would
remove all backslashes and leave only the following character.
nm_utils_escaped_tokens_split() instead only strips backslashes
that preceed a delimiter, whitespace or another backslash.
But we should have one preferred way of tokenizing, and I find this
preferable, because it allows for most backslashes to appear verbatim.
This escapes strings so that they can be concatenated with a delimiter
and without loss tokenized with nm_utils_escaped_tokens_split().
Note that this is similar to _nm_utils_escape_plain() and
_nm_utils_escape_spaces(). The difference is that
nm_utils_escaped_tokens_escape() also escapes the last trailing
whitespace. That means, if delimiters contains all NM_ASCII_SPACES, then
it is identical to _nm_utils_escape_spaces(). Otherwise, the trailing
space is treated specially. That is, because
nm_utils_escaped_tokens_split() uses NM_UTILS_STRSPLIT_SET_FLAGS_STRSTRIP,
to strip leading and trailing whitespace. To still express a trailing
whitespace, the last whitespace must be escaped. Note that
NM_UTILS_STRSPLIT_SET_FLAGS_STRSTRIP also honors escaping any whitespace
(not only at the last position), but when escaping we don't need to
escape them, because unescaped (non-trailing) whitespace are taken just
fine.
The pair nm_utils_escaped_tokens_split() and
nm_utils_escaped_tokens_escape() are proposed as default way of
tokenizing a list of items. For example, with
$ nmcli connection modify "$PROFILE" +ipv4.routing-rules 'priority 5 from 192.168.7.5/32 table 5, priority 6 iif a\, from 192.168.7.5/32 table 6'
Here we implement a to/from string function to handle one item
(nm_ip_routing_rule_{from,to}_string()). When such elements are combined with ',',
then we need to support an additional layer of escaping on top of that.
The advantage is that the indvidual to/from string functions are agnostic
to this second layer of escaping/tokenizing that nmcli employs to handle
a list of these items.
The disadvantage is that we possibly get multiple layers of backslash
escapings. That is only mitigated by the fact that nm_utils_escaped_tokens_*()
supports a syntax for which *most* characters don't need any special escaping.
Only delimiters, backslash, and the trailing space needs escaping, and
these are cases are expected to be few.
Add a new flag that will remove escape characters after splitting
the string.
This implements a special kind of backslash escaping. It's not C escape
sequences (like '\n' or '\020'), but simply to take the special character
following the backslash verbatim. Note that the backslash is only
considered special, if it's followed by a delimiter, another backslash,
or a whitespace (in combination with %NM_UTILS_STRSPLIT_SET_FLAGS_STRSTRIP).
The main purpose of this form of escaping is nmcli's list options, like
$ nmcli connection modify "$PROFILE" +ipv4.routing-rules 'priority 5 from 192.168.7.5/32 table 5, priority 6 iif a\, from 192.168.7.5/32 table 6'
It's a contrieved example, but the list options are a list of IP
addresses, rules, etc. They implement their own syntax for one element,
and are concatenated by ','. To support that one element may have
arbitrary characters (including the delimiter and whitespaces), nmcli
employs a tokenization with this special kind of escaping.
This will essentially call g_strstrip() on each token.
There are some specialties:
- if the resulting word is empty after stripping, then according to
%NM_UTILS_STRSPLIT_SET_FLAGS_PRESERVE_EMPTY, the empty token will be
removed. If that results in an empty string array, %NULL will be
returned.
- if %NM_UTILS_STRSPLIT_SET_FLAGS_ALLOW_ESCAPING is set, then
whitespace that is backslash escaped is not removed.
Since this is a post-operation that happens after tokeninzing, it
could be done as a separate function. And we already have this function:
_nm_utils_unescape_plain() and _nm_utils_unescape_spaces().
However, that is ugly for several reasons:
- the stripping should be part of the tokenizing, you shouldn't need
several steps.
- nm_utils_strsplit_set_full() returns a "const char **" which
indicates the strings must not be freed. However, it is perfectly
valid to modify the string inplace. Hence, the post-op function
would need to cast the strings to "char *", which seems ugly
(although we do that on many places, and it's guaranteed to work).
- _nm_utils_unescape_plain()/_nm_utils_unescape_spaces() is indeed
already used together with nm_utils_strsplit_set_full(). However,
it requires to initialize the cb_lookup buffer twice. I would expect
that initializing the cb_lookup buffer is a large portion of what
the function does already (for short strings).
This issue will be solved in the next commit by adding yet another flag
which allows to unescape.
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
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/".
