binary-search can find an index of a matching entry in a sorted
list. However, if the list contains multiple entries that compare
equal, it can be interesting to find the first/last entry. For example,
if you want to append new items after the last.
Extend binary search to optionally continue the binary search
to determine the range that compares equal.
(cherry picked from commit d83eee5d57)
"no_value" indicates that the the attribute is a single word, not a
key=value pair. If the type is BOOLEAN then the attribute is considered
true, if it's a STRING then the key is used instead of a value.
"consumes_rest" indicates that the particular key takes the unparseable
tail of the string for a value.
This allows parsing tc-style strings. Consider this filter:
,------ regular key/value pair
,-----'----.
root handle 1234: matchall action simple foo bar baz
| | `-----------.-----------'
| | `- "", STRING, consumes_rest
| `------------------- "kind", STRING, no_value
`-------------------------------------- "root', BOOLEAN, no_value
(cherry picked from commit 47b1dc3828)
till now when no explicit value was set on a property, the default value
for that property was returned, also if the property was not applicable
to the selected runner.
Fix this, showing default values for properties only when relevant and
showing instead -1 or null when the property is not relevant for the
selected runner.
Moreover, reset all the properties but the link-watchers when the team.runner
is changed: this is required to clean up the properties unrelated to the
new runner and start with the runner-specific defaults.
(cherry picked from commit a5642fd93a)
Move code from _nm_utils_team_config_get to the brand new
_json_team_add_defaults function without any change.
Then remove the duplicated code from _nm_utils_team_config_equal and
leverage the new function. Here the only functional change is that
the defaults for "notify_peers" and "mcast_rejoin" for the
"activebackup" runner are added (the only case in which their default
values are different than 0).
(cherry picked from commit fdd41852ee)
When jansson lib version is < 2.8 the order of the keys of json objects
is not preserved automatically. In particular, when loading the json
string, parsing it and dumping it back to a string the key order will be
lost if the now deprecated JSON_PRESERVE_ORDER flag is not set.
Add the flag: will do nothing on recent jansson versions but will fix
behavior for legacy ones.
(cherry picked from commit 5e6f7de4be)
We should use the same str2bool parser everywhere: _nm_utils_ascii_str_to_bool().
Incidentally, this function allows more forms of expressing a boolean
value.
$ nmcli connection modify "$CON" ipv4.routes '1.2.3.4/32 1.2.3.1 onlink=1'
Error: failed to modify ipv4.routes: invalid option 'onlink=1': invalid boolean value '1' for attribute 'onlink'.
(cherry picked from commit 26e7abc65e)
We want to support large number of routes. Reduce the number
of copies, by adding internal accessor functions.
Also, work around a complaint from coverity:
46. NetworkManager-1.9.2/libnm-core/nm-utils.c:1987:
dereference: Dereferencing a null pointer "names".
Since kernel commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 (net:
reject creation of netdev names with colons), kernel rejects any
colons in the interface name.
Since kernel could get away with tightening up the check, we can
too.
The user anyway can not choose arbitrary interface names, like
"all", "default", "bonding_masters" are all going to fail one
way or another.
teamd adds the "tx_hash" property for "lacp" and "loadbalance" runners
when not present. Do the same so that our original configuration
matches with the one reported by teamd.
https://bugzilla.redhat.com/show_bug.cgi?id=1497333
By using a macro, we don't cast all the types to guint. Instead,
we use their native types directly. Hence, we don't need
nm_hash_update_uint64() nor nm_hash_update_ptr().
Also, for types smaller then guint like char, we save hashing
the all zero bytes.
The privious NM_HASH_* macros directly operated on a guint value
and were thus close to the actual implementation.
Replace them by adding a NMHashState struct and accessors to
update the hash state. This hides the implementation better
and would allow us to carry more state. For example, we could
switch to siphash24() transparently.
For now, we still do a form basically djb2 hashing, albeit with
differing start seed.
Also add nm_hash_str() and nm_str_hash():
- nm_hash_str() is our own string hashing implementation
- nm_str_hash() is our own string implementation, but with a
GHashFunc signature, suitable to pass it to g_hash_table_new().
Also, it has this name in order to remind you of g_str_hash(),
which it is replacing.
"nm-utils/nm-shared-utils.h" shall contain utility function without other
dependencies. It is intended to be used by other projects as-is.
nm_utils_random_bytes() requires getrandom() and a HAVE_GETRANDOM configure
check. That makes it more cumbersome to re-use "nm-shared-utils.h", in
cases where you don't care about nm_utils_random_bytes().
Split nm_utils_random_bytes() out to a separate file.
Same for hash utils, which depend on nm_utils_random_bytes(). Also, hash
utils will eventually be extended to use siphash24.
Introduce a NM_HASH_INIT() function. It makes the places
where we initialize a hash with a certain seed visually clear.
Also, move them from "shared/nm-utils/nm-shared-utils.h" to
"shared/nm-utils/nm-macros-internal.h". We might want to
have NM_HASH_INIT() non-inline (hence, define it in the
source file).
GArray's and GPtrArray's plen argument is unsigned. The index variable
to iterate the list, should not have a smaller range (or different data type).
Also, assert against negative idx argument.
CC libnm-core/libnm_core_libnm_core_la-nm-utils.lo
libnm-core/nm-utils.c:210:6: error: variable 'encodings' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (lang) {
^~~~
libnm-core/nm-utils.c:220:7: note: uninitialized use occurs here
if (!encodings) {
^~~~~~~~~
libnm-core/nm-utils.c:210:2: note: remove the 'if' if its condition is always true
if (lang) {
^~~~~~~~~~
libnm-core/nm-utils.c:198:30: note: initialize the variable 'encodings' to silence this warning
const char *const *encodings;
^
= NULL
Fixes: 28a0627481
Using plain numbers make it cumbersome to grep for
setting types by priority.
The only downside is, that with the enum values it
is no longer obvious which value has higher or lower
priority.
Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
_nm_setting_type_get_base_type_priority() returns. For the moment
it still has the same numerical value 0 as before. Later, that
shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
Teamd is not happy about them and would fail anyway. Worse even, if we
json_loads() such a JSON, which is precisely what happens when we inject the
"hwaddr" key, we turn bad JSON into a good one in a lossy matter. Not good.
https://bugzilla.redhat.com/show_bug.cgi?id=1455130
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
Commit a8730c51c8 moved the enum
utils from libnm-core to shared/nm-utils.
However, three of those functions are part of public API in libnm.
So, when statically linking against "shared/nm-utils/nm-enum-utils.c"
and dynamically linking against libnm.so, those symbols are present
twice and cause a linker failure.
Fix that by moving the public API back to libnm-core.
Fixes: a8730c51c8
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.
nm_utils_enum_to_str() may also output numeric values if there is no
corresponding "nick" for the enum/flag value.
For enums the value is in decimal and for flags the value is hexadecimal
(with a "0x" prefix).
The same was already supported by nm_utils_enum_from_str() when reading
the value. However, previously, reading a flag would only support hex
numbers and reading a enum would only support decimal numbers.
Extend that, to allow passing numbers in any base. For nm_utils_enum_to_str()
also make sure to never output nicks that may be misinterpreted as
numbers.
It is not uncommon that a flags type has also the value 0 mapped,
for example to "unknown" or "none".
In that case, we should not return an empty string, but instead
that zero value.
Also, flags actually have an unsigned type. That isn't a real
problem to cast it to a signed int. But be more careful about
it and use unsigned while handling unsigned values and only
cast to int once.
