libnm-core-impl has lots of internal meta data about the properties. In particular, which properties exist (their names), and their D-Bus type. We should use this information for our manual pages. For example, currently `man nm-settings-dbus` has nonsense like: "Value Type: array of string", when it should be reall "as". In a first step, generate an XML with that meta data for later use.
Add a comment. Also, restructure the check so that it is (hopefully) easier to read.
nm_setting_diff() ends up calling the compare_fcn() hook. Previously,
the hook for "dns" was _nm_setting_property_compare_fcn_default()
and the hook for "dns-data" was _nm_setting_property_compare_fcn_ignore().
That's wrong. _nm_setting_property_compare_fcn_default() converts
the property to D-Bus and compares the GVariant. However, "dns" has
to_dbus_only_in_manager_process set, so it wouldn't
Fixes: 63eaf168d1b8 ('libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus')
property_to_dbus() gets called for two reasons. Once from
_nm_setting_to_dbus(). In that case, we want to honor
to_dbus_only_in_manager_process().
It gets also called from _nm_setting_property_compare_fcn_default(),
with ignore_flags set. In that case, we don't want to ignore the property
as the hook really wants to compare them.
Fixes: c8392018ca19 ('libnm: refactor to-dbus on the client skipping to serialize legacy properties')
Just gives a better failure message. These checks fail often, when new code gets added.
Unfortunately, for this we require SetLinkDNSEx() API from v246. That adds extra complexity. If the configuration contains no server name, we continue using SetLinkDNS(). Otherwise, at first we try using SetLinkDNSEx(). We will notice if that method is unsupported, reconfigure with SetLinkDNS(), and set a flag to not try that again.
- nm_setting_ip_config_add_dns() and nm_setting_ip_config_remove_dns_by_value() used to assert that the provided input is valid. That is not documented and highly problematic. Our parsing code for keyfile, ifcfg-rh and GVariant rightly just call add. Likewise, nmcli. We cannot reasonably expect them to pre-validate the input. Why would we anyway? This is wrong in particular because we usually want the user to be able to construct invalid settings. That is often necessary, because whether a value is valid depends on other values. So in general, we can only validate when all properties are set. We have nm_connection_verify() for that, and asserting/validating during add is very wrong. Note that "add" still filters out duplicates, which may be an inconsistency, but well. Also, the user could set any bogus value via the NM_SETTING_IP_CONFIG_DNS property. Those should be allowed to be removed, and the same values should be allowed to be added via the add method. - add() does a normalization, presumably so that the values look nice. Do the same normalization also when using the NM_SETTING_IP_CONFIG_DNS property setter. - previously, the setter could also set unnormalized values. As nm_setting_ip_config_remove_dns_by_value() looked for the normalized value, you couldn't remove such values anymore. That is fixed now, by letting the property setter do the same normalization. - don't allocate a GPtrArray unless we need it. No need for the extra allocation. - in the property setter, first set the new value before destroying the previous GPtrArray. It might not be possible, but it's not clear to me whether the strv argument from the GValue is always deep-copied or whether it could contain strings to the DNS property itself.