Previously, g_hash_table_get_keys() would already allocate a
GList list, which then gets copied to another GSList.
Don't do that. Just allocate one array to keep all the
elements.
Also, as we now use nm_setting_vpn_get_secret_keys() and
nm_setting_vpn_get_data_keys(), note that the keys are sorted
and hence the order is stable.
It's rather limiting that the only API to access *all* keys
is nm_setting_vpn_foreach_data_item() and nm_setting_vpn_foreach_secret().
API like nm_setting_vpn_get_num_secrets() is not useful, at least as
long as you cannot access the item by index.
There is no principle problem with returning zero has hash
value. But just don't do it. Our hash functions should not
return zero. Instead, return nm_hash_static(). This is why
the function exists.
GNU less supports filters. That makes it nice to use instead of cat.
Also, less is well suited for output to a pipe.
With this, `NM-log nm-log.txt.gz` works as you would expect
It is common to have some data indexed by a name.
If you want to sort a list of such data, you would
have to re-implement your own compare function each time.
Instead, add NMUtilsNamedEntry which as first field has
the name. So, you can create your own struct:
struct my_data {
const char *name;
... other fields
}
and compare them with with nm_utils_named_entry_cmp().
For convenience, add another struct NMUtilsNamedValue, which
has only one data field, a pointer.
Settings plugins now return the connection that was reread from file
when adding a connection, which means that any agent-owned secret is
lost. Ensure that we don't forget agent-owned secrets by caching them
and readding them to the new connection returned by plugins.
Fixes: 8a1d483ca8
Fixes: b4594af55ehttps://bugzilla.gnome.org/show_bug.cgi?id=789383
Bond options are stored in a hash table and the order in which they
are returned by the API is not guaranteed. Sort them alphabetically so
that a connection will always be written in the same way, even if the
internal implementation of the hash table or the hashing function
changes, as it did in commit a6be2f4aa9 ("all: use nm_str_hash()
instead of g_str_hash()").
Matters when backslash escaping ascii charaters <= 0xF, to
produce "\\XX" instead of "\\ X". For example tabulator is "\\09".
This also can trigger an nm_assert() failure, when building with
--with-more-asserts=5 (or higher).
check_and_add_ipv6ll_addr() checks whether a link-local address is
already present in priv->ip6_config and if so, it returns with no
action.
priv->ip6_config is only updated after a merge-and-apply or (in an
idle source) when the external configuration changes and so there is
no guarantee that the addresses there are up-to-date.
priv->ext_ip6_config_captured should be checked instead, because it is
updated from platform right before starting the generation of a
link-local address. Note that also linklocal6_start() already checks
the captured external configuration rather than priv->ip6_config.
https://bugzilla.redhat.com/show_bug.cgi?id=1500350
Fix resolved detection, the symlink target is usually relative to the
root, such that in chroots the file points to a file inside the
chroot. But keep absolute targets too, as these may have been in use
with older version of systemd. Add support for stub-resolv.conf
detection.
https://bugzilla.gnome.org/show_bug.cgi?id=790446
If a device is 'external' (which means that NM generated an in-memory
connection to only to track the device state) we should not change its
IP configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
In the next commit we will modify ipX_config_merge_and_apply to never
touch external devices. When a "reapply" call is issued on an external
device we are no longer simply tracking its state but we are actively
managing it and so its sys-iface-state must be promoted to managed.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
Don't reset existing routes if ipvx.ignore-auto-routes=yes: callers
should already avoid adding them when not needed.
Previously we would also reset the manual gateway route just added.
Fixes: 5c299454b4https://bugzilla.gnome.org/show_bug.cgi?id=790423
This allows the compiler to inline the siphash24*() functions
for nm_hash_ptr() and nm_hash_str() (even without LTO).
This of course only applies to nm_hash_ptr() and nm_hash_str(),
which are implemented in "nm-hash-utils.c" itself. All other
nm_hash_*() functions are inline functions in "nm-hash-utils.h",
and thus these functions can be inlined instead. That is, in
other cases, the nm_hash_*() function instead can be inlined.
For nm_hash_ptr() and nm_hash_str() instead we want to inline the
siphash24*() functions.
So, no longer compile "siphash24.c" directly. Instead, only
build "nm-hash-utils.c" which internally #include "siphash24.c".
We also do this for libnm and libnm-core, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
GHashTable optimizes a NULL equality function to use direct pointer
comparison. That saves the overhead of calling g_direct_equal().
This is also documented behavior for g_hash_table_new().
While at it, also don't pass g_direct_hash() but use the default
of %NULL. The behavior is the same, but consistently don't use
g_direct_hash().
Next we will use siphash24() instead of the glib version g_direct_hash() or
g_str_hash(). Hence, the "nm-utils/nm-hash-utils.h" header becomes very
fundamental and will be needed basically everywhere.
Instead of requiring the users to include them, let it be included via
"nm-default.h" header.
siphash24() mixes the bits much better then our naive xor.
Don't bypass siphash24(). We supposedly use it for the
better hashing properties, so use it also for pointers.
