libnm: add API for setting gendata options to NMSetting (nm_setting_option_get())

NMSettingEthtool is implemented using "gendata", meaning a hash
of GVariant. This is different from most other settings that have
properties implemented as GObject properties. There are two reasons
for this approach:

  - The setting is transferred via D-Bus as "a{sv}" dictionary.
    By unpacking the dictionary into GObject properties, the setting
    cannot handle unknown properties. To be forward compatible (and
    due to sloppy programming), unknown dictionary keys are silently
    ignored when parsing a NMSetting. That is error prone and also
    prevents settings to be treated loss-less.
    Instead, we should at first accept all values from the dictionary.
    Only in a second step, nm_connection_verify() rejects invalid settings
    with an error reason. This way, the user can create a NMSetting,
    but in a separate step handle if the setting doesn't verify.
    "gendata" solves this by tracking the full GVariant dictionary.
    This is still not entirely lossless, because multiple keys are
    combined.
    This is for example interesting if an libnm client fetches a connection
    from a newer NetworkManager version. Now the user can modify the
    properties that she knows about, while leaving all unknown
    properties (from newer versions) in place.

  - the approach aims to reduce the necessary boiler plate to create
    GObject properties. Adding a new property should require less new code.

This approach was always be intended to be suitable for all settings, not only
NMSettingEthtool. We should not once again try to add API like
nm_setting_ethtool_set_feature(), nm_setting_ethtool_set_coalesce(), etc.
Note that the option name already fully encodes whether it is a feature,
a coalesce option, or whatever. We should not have
"nm_setting_set_$SUB_GROUP (setting, $ONE_NAME_FROM_GROUP)" API, but
simply "nm_setting_option_set (setting, $OPTION)" accessors.

Also, when parsing a NMSettingEthtool from a GVariant, then a feature
option can be any kind of variant. Only nm_setting_verify() rejects
variants of the wrong type. As such, nm_setting_option_set*() also
doesn't validate whether the variant type matches the option. Of course,
if you set a value of wrong type, verify() will reject the setting.

Add new general purpose API for this and expose it for NMSetting.

1 files changed, 1 insertions, 0 deletions

diff --git a/libnm/libnm.ver b/libnm/libnm.ver
index effa41d162..97cdc06a83 100644
--- a/libnm/libnm.ver
+++ b/libnm/libnm.ver
@@ -1732,4 +1732,5 @@ global:
 	nm_setting_match_remove_driver_by_value;
 	nm_setting_match_remove_kernel_command_line;
 	nm_setting_match_remove_kernel_command_line_by_value;
+	nm_setting_option_get;
 } libnm_1_24_0;