We have
- svGetValue()
- returns the original string
- avoids copying the string unless necessary
- svGetValueStr_cp() (formerly svGetValueString())
- returns the original string, unless it is empty ""
- always clones the string
I think the behavior svGetValueStr*() of coercing "" to NULL is wrongly
used in most places. We should better handle "" like any other value,
not treat it as unset.
That would require another function svGetValue_cp(), which is like svGetValue()
but always copies the string. Rename svGetValueString() so that there is a place
for names like
- svGetValue_cp()
- svGetValueStr()
Also rename svSetValueString() to svSetValueStr().
Ifcfg reader now properly handles escaping and quoting. We don't
need to stip whitespace, if somebody explicitly configures
prop=" value"
it is a configuration error.
ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
We want to have some guaranteed order when comparing different connections.
So, in case of equal timestamps, proceed with comparing more properties.
It makes sense to consider the autoconnect-priority next.
This is what get_existing_connection() needs, thus we no longer
need to pre-sort the list.
NMPolicy's auto_activate_device() wants to sort by autoconnect-priority,
nm_utils_cmp_connection_by_autoconnect_priority() but fallback to the default
nm_settings_connection_cmp_default(), which includes the timestamp.
Extend nm_settings_connection_cmp_default() to consider the
autoconnect-priority as well. Thus change behavior so that
nm_settings_connection_cmp_default() is the sort order that
auto_activate_device() wants. That makes sense, as
nm_settings_connection_cmp_default() already considered the
ability to autoconnect as first. Hence, it should also honor
the autoconnect priority.
When doing that, rename nm_settings_connection_cmp_default()
to nm_settings_connection_cmp_autoconnect_priority().
We call these functions a lot. A GSList is just the wrong tool for the
job. Refactor the code to use instead a sorted array everywhere.
This means, we malloc() one array for all connections instead
slice-allocate a GSList item for each. Also, sorting an array
is faster then sorting a GSList.
Technically, the GSList implementation had the same big-O runtime
complexity, but using an array is still faster. That is, sorting
an array and a GSList is both O(n*log(n)).
Actually, nm_settings_get_connections_sorted() used
g_slist_insert_sorted() instead of g_slist_sort(). That results
in O(n^2). That could have been fixed to have O(n*log(n)), but
instead refactor the code to use an array.
nm_settings_get_best_connections() has only one caller: to create
the hidden-SSID list.
Instead of having a highly specialised function (that accepts 3 ways for
filtering -- one of them broken, has one hard-coded way of sorting, and
a @max_requested argument), add a more generic nm_settings_get_connections_clone()
function.
Also invert nm_settings_sort_connections(). The two callers want
to sort descending, not ascending.
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
(cherry picked from commit f0e3dfdace)
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
Use nm_utils_fd_get_contents() which has precisely all the steps implemented
to read data from a file descriptor.
There is a downside to this: previously you could compile shvar.c without
nm-core-utils.c. Now, the ifcfg implementation gained a dependency
on NM core utils. That would matter if we one day would like to build
shvar.c without core NetworkManager utils (but that is not planned).
Pre-process each line and parse the key and value.
Thus, keep the key already prepared.
The point is to do the parsing early and keep the
data in a more suitable format in shvarLine.
The shlist_delete*() are now named wrong, as they don't delete
the list entry. Anyway, they have only one caller, it's clearer
to inline them.
This way, during svSetValue() we need to iterate the entire
list only once.
