It's not the job of keyfile writer to enforce certain settings. A
%NULL GBytes property is shall be treated distinct from a byte array
with zero length.
The NMSetting may or may not reject such settings as invalid during
verify() or mangle them during normalize(). But reader/writer should
just serialize every property as-is.
We use write_array_of_uint() for G_TYPE_ARRAY. In practice, only
NMSettingDcb has any properties of this type.
Furthermore, all valid values are either gboolean or guints of
restricted range. Thus, no valid NMSettingDcb should violate the
range check.
Same for reader.
It's really ugly to blindly use uint-list reader for G_TYPE_ARRAY.
Especially, because certain G_TYPE_ARRAY properties of NMSettingDcb
are actually arrays of gboolean, which only ~accidentally~ has the same
memory layout as guint.
No longer use a regex to pre-evaluate whether @tmp_string looks
like a integer list. Instead, parse the integer list ourself.
First, drop the nm_keyfile_plugin_kf_has_key() check.
Note that this merely verifies that such a key exits. It's rather
pointless, because get_bytes() is only called for existing keys.
Still, in case the check would actually yield differing results
from the following nm_keyfile_plugin_kf_get_string(), we want to
act depending on what nm_keyfile_plugin_kf_get_string() returns.
Note that nm_keyfile_plugin_kf_get_string() looks up the key, alternatively
fallback to the settings alias. Then, GKeyFile would parse the raw keyfile
value and return it as string.
Previously, we would first decide whether @tmp_string look like a integer list
to decide wether to parse it via nm_keyfile_plugin_kf_get_integer_list().
But note that it's not clear that nm_keyfile_plugin_kf_get_integer_list()
operates on the same string as nm_keyfile_plugin_kf_get_string().
Could it decide to return different strings based on whether such
a key exists?
E.g. when setting "802-11-wireless.ssid=foo" and "wifi.ssid=60;" they
clearly would yield differing results: "foo" vs. [60].
Ok, probably it is not an issue because we call first
nm_keyfile_plugin_kf_get_string(), decide whether it looks like a
integer list, and return "foo" right away.
This is still confusing and relyies on knowledge about how the value
is encoded as string-list.
Likewise, could our regex determine that the value looks like a integer
list but then the integer list is unable to parse it? Certainly that can
happen for values larger then 255.
Just make it consistent. Get *one* @tmp_string. Try (manually) to
interpret it as string list, or bail using it as plain text.
Also, allow returning empty GBytes arrays. If somebody specifies an
empty list, it's empty. Not NULL.
The only implementations were there for tracking the parent device.
That is now donw via nm_device_parent_*(), parent_changed_notify()
and _parent_notify_changed().
Multiple subclasses have a parent/link interface (NMDeviceIPTunnel,
NMDeviceVlan). Tracking the parent interface properly is midly
complicated to get right. So, instead of repeating it in each
subclass, track it in the parent device.
Move the updating/setting of the ip-ifindex/ip-iface to one place.
Properties should be for the most part immutable/read-only, and only
at particular places modified. That way, it's easier to track who
changes a property.
Also, add a logging line with "ip-ifname" prefix.
Most implementations of realize_start_notify() do the same
for link_changed().
Let NMDevice's base implementation of realize_start_notify() call
link_changed() -- which by default does notthing. This allows subclasses
to only overwrite link_changed().
Instead of overwriting constructed(), update the s390 subchannels via
realize_start_notify(). This makes more sense and is also more similar
to what other device implementations do.
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().
Instead of creating a GSList use an array. That way, we save
the allocation and free of an GSList instance. Also, avoid
cloning the export path. It is stable.
Previously, due to a bug in "tools/enums-to-docbook.pl", enum values
without explicit numeric value were wrongly parsed. That is fixed,
but still explicitly set the value in the public header.
Previously, an enum that didn't explicitly specify a numeric value
would wrongly start counting at 1.
E.g.
typedef enum {
MY_VAL,
} Name;
would result in documentation with MY_VAL=1.
https://bugzilla.gnome.org/show_bug.cgi?id=776848
Only use non-negative index values for the D-Bus path. This is purely
cosmetical, as the actual path value should be treated as opaque. Still,
avoid using 0 and start counting at 1.
An overflow of the 32 bit guint is possible and rather ugly
because the D-Bus path should be unique and not repeat.
Avoid that by extending the counter to 64 bit.
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.
