Instead of using a macro to define the individual set/remove functions,
add a new property type _pt_multilist.
This way, we have more the concept of a property having a type, instead
of a property having a set of handlers how to implement something.
Also, this is only the first step. There are several similar properties
that also can be implemented as the same type.
The property implementation must itself decide how to reset a value.
We must not rely on properties being plain GObject properties.
Let set_fcn() accept %NULL value to indicate resetting the default.
Previously we had DEFINE_REMOVER_INDEX_OR_VALUE_DIRECT() and
DEFINE_REMOVER_INDEX_OR_VALUE_VALIDATING_STATIC().
Note that all property-infos of DEFINE_REMOVER_INDEX_OR_VALUE_VALIDATING_STATIC()
would also define values_static list, while DEFINE_REMOVER_INDEX_OR_VALUE_DIRECT()
would not.
Merge the two macros. The property-info should define how the
implementation behaves, we should not have two implementations.
set_fcn() of NM_SETTING_802_1X_EAP is implemented via
DEFINE_SETTER_STR_LIST_MULTI() -- thus, considering valid values
from the static list.
The remove_fcn() should do that too, to be consistent.
We don't need DEFINE_SETTER_STR_LIST_MULTI() to define a static function
that is called by the set_fcn() implementation. Instead, let the macro
define the actual set_fcn() function.
It's fundamentally wrong to have separate "remove_fcn" and "set_fcn"
implementations. Set, reset, add, and remove are all similar, and should
be implemented in a similar manner.
Merge the implementations all in set-property, which now can:
- reset the value (value == NULL && modifier == '\0')
- set a value (value != NULL && modifier == '\0')
- add a value (value != NULL && modifier == '+')
- remove a value (value != NULL && modifier == '-')
The real problem is that remove_fcn() behaves fundamentally different
from set_fcn(). You can do "+setting.property value1,value2" but you
cannot remove them the same way. That is because most remove_fcn()
implementations don't expect a list of values. But it's also because of
the unnatural split between set_fcn() and remove_fcn().
The next commit will merge set_fcn(), remove_fcn() and reset property.
This commit just merges them all in nmc_setting_set_property().
ipv4_method_changed_cb() and ipv6_method_changed_cb() are horrible hacks, as they
use a static variable to cache the previous value.
Anyway, don't fix that now.
We are going to drop nmc_property_get_gvalue()/nmc_property_set_gvalue()
because that works only with GObject based properties -- and having this
API around wrongly suggests it works in general. Use the native types
directly.
"reset" is just a special case of "set". We can keep nmc_setting_reset_property() as a convenience
function, but it must be implemented based on nmc_setting_set_property().
Also, reset only used nmc_property_set_default_value(), which only works
with GObject based properties. It's wrong to assume that all properties
are GObject based. By implementing it based via nmc_setting_set_property()
we can fix this (later).
Not all implementations support having the value being an index.
For example, the implementations that are done via DEFINE_REMOVER_OPTION() macro.
The meaning of the "value" string must not be determined by
nmc_setting_remove_property_option(). It's up to the implementation
to decide whether to allow an index and how to interpret it.
$ nmcli connection add type vlan autoconnect no con-name v dev vlan.1 id 1
$ nmcli connection modify v +vlan.ingress-priority-map 1:2,2:3
$ nmcli connection modify v +vlan.ingress-priority-map 2:3,4:5
$ nmcli connection modify v -vlan.ingress-priority-map 1:2,4:5
Warning: only one mapping at a time is supported; taking the first one (1:2)
Part 1, which addresses the issue for simple properties that have
a plain remove-by-value function.
Rationale:
Removing a value/index that does not exist should not be a failure.
Woule you like:
$ nmcli connection modify "$PROFILE" autoconnect no
$ nmcli connection modify "$PROFILE" autoconnect no
Error: autoconnect is already disabled
So, why would it be a good idea to fail during
$ nmcli connection modify "$PROFILE" -vpn.data ca
$ nmcli connection modify "$PROFILE" -vpn.data ca
Error: failed to remove a value from vpn.data: invalid option 'ca'.
Generally, it should not be an error to remove an option, as long
as the option itself is valid. For example,
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map bogus
should fail, but
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map 1:5
should succeed even if there was nothing to remove.
The "from" part is like a key for the egress/ingress priority map.
Extend nm_setting_vlan_remove_priority_str_by_value() to accept only the
"from" part when finding and deleting value. This allows for:
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '4:'
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '4:*'
to fuzzy match the value to remove.
How hard can it be to use strtol()? Apparently very. You need to check
errno, the endpointer, and also not pass in an empty string.
Previously, nmc_string_to_uint_base() would silently accept "" as valid
number. That's a bug.
Btw, let's not use strtol() (or nmc_string_to_uint*()). We have
_nm_utils_ascii_str_to_int64(), which gets all of this right.
The same code is used by nmcli. Obviously, clients also need to
parse string representations.
That begs the question whether this should be public API of libnm.
Maybe, but don't decide that now, just reuse the code internally via
"shared/nm-libnm-core-utils.h".
We have code in "shared/nm-utils" which are general purpose
helpers, independent of "libnm", "libnm-core", "clients" and "src".
We have shared code like "shared/nm-ethtool-utils.h" and
"shared/nm-meta-setting.h", which is statically linked, shared
code that contains libnm related helpers. But these helpers already
have a specific use (e.g. they are related to ethtool or NMSetting
metadata).
Add a general purpose helper that:
- depends (and extends) libnm-core
- contains unrelated helpers
- can be shared (meaning it will be statically linked).
- this code can be used by any library user of "libnm.so"
(nmcli, nm-applet) and by "libnm-core" itself. Thus, "src/"
and "libnm/" may also use this code indirectly, via "libnm-core/".
- avoid the memory allocations by not using g_strsplit().
- add a helper function priority_map_parse_str(). This will
be used later, to avoid allocating a NMVlanQosMapping
result, when we don't need it on the heap.
- for the priority mappings, the "from" part is the key and must
be unique. As such, it would make sense to say
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '1:*'
or
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '1:'
to delete any mapping for that priority, regardless of the "to" part.
Add an option to leave the "to" part unspecified. This will be used
later.
nm_utils_parse_inaddr() is trivial enough to reimplement it, instead of calling
nm_utils_parse_inaddr_bin(). Calling nm_utils_parse_inaddr_bin() involves several
things that don't matter for nm_utils_parse_inaddr() -- like assigning
out_addr_family or returning the binary address.
- use nm_auto_decref_json for "json_value" to indicate ownership
transfer.
- don't reuse variable json_element and json_link to construct
watchers list. It's confusing. In general, use different variables
for different purposes.
_nm_utils_team_config_get() determines the type based on the JSON content.
Hence, the caller must validate that the returned GValue is of the expected
type, or it will trigger an assertion/crash.
Use nm_auto*, it's almost always harder to get wrong, because
ownership (and lifetime management of a variable, and what it points
to) is more clearly expressed.
