Instead of having a trivial macro that defines a function, define the
function directly.
Having such a macro would make sense if DEFINE_REMOVER_OPTION() would do
the right thing and we would reuse the (preferred) implementation.
That's not the case, because these remove_fcn() implementations don't
mirror the way how set_fcn() splits and sets options. They are
inconsistent (wrong), and should will later get merged with set_fcn().
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.
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.
Rework the explicit implementation of NM_SETTING_802_1X_PASSWORD_RAW
handling to generically handle GBytes properties.
Note that the NM_SETTING_802_1X_PASSWORD_RAW setter accepts a legacy
format where hex-words are separated by space. I don't think we want
to support this format for new options.
So, there are two possibilities:
1) either leave _set_fcn_802_1x_password_raw() as-is, with the special
handling.
2) interpret a property-data gobject_bytes.legacy_format.
1) seems to make more sense, because there is only one such property,
and we won't use this for new properties. However let's do 2), because
it shows nicely the two styles side-by-side. In other words, let's
password-raw also be a _pt_gobject_bytes typed property, with some
special legacy handling. Instead, of having it an entirely separate
property type (with a different setter implementation). I think it's
better to have the parts where they differ pushed down (the "stack") as
much as possible.
- it's less lines of code (for the caller).
- it's a function that can be easier unit-tested on its own.
Possibly there are already other unit-tests that cover it.
- it's more efficient than the GString based implementation.
- it reuses our one and only bin-to-hexstr implementation.
For now only add the core settings, no peers' data.
To support peers and the allowed-ips of the peers is more complicated
and will be done later. It's more complicated because these are nested
lists (allowed-ips) inside a list (peers). That is quite unusual and to
conveniently support that in D-Bus API, in keyfile format, in libnm,
and nmcli, is a effort.
Also, it's further complicated by the fact that each peer has a secret (the
preshared-key). Thus we probably need secret flags for each peer, which
is a novelty as well (until now we require a fixed set of secrets per
profile that is well known).
