2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2011 Red Hat, Inc.
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
all: fix up multiple-include-guard defines
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
2014-08-13 14:10:11 -04:00
|
|
|
#ifndef __NM_SETTING_PRIVATE_H__
|
|
|
|
|
#define __NM_SETTING_PRIVATE_H__
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#if !((NETWORKMANAGER_COMPILATION) &NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_PRIVATE)
|
|
|
|
|
#error Cannot use this header.
|
2018-01-02 13:37:06 +01:00
|
|
|
#endif
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
#include "nm-setting.h"
|
2019-03-16 17:21:35 +01:00
|
|
|
#include "nm-setting-bridge.h"
|
2014-08-06 19:35:31 -04:00
|
|
|
#include "nm-connection.h"
|
2014-08-07 17:19:40 -04:00
|
|
|
#include "nm-core-enum-types.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2014-08-11 18:10:43 +02:00
|
|
|
#include "nm-core-internal.h"
|
|
|
|
|
|
libnm: use NMMetaSettingInfo for tracking setting priority
Previously, each (non abstract) NMSetting class had to register
its name and priority via _nm_register_setting().
Note, that libnm-core.la already links against "nm-meta-setting.c",
which also redundantly keeps track of the settings name and gtype
as well.
Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
data.
The goal is to get rid of private data structures that track
meta data about NMSetting classes. In this case, "registered_settings"
hash. Instead, we should have one place where all this meta data
is tracked. This was, it is also accessible as internal API,
which can be useful (for keyfile).
Note that NMSettingClass has some overlap with NMMetaSettingInfo.
One difference is, that NMMetaSettingInfo is const, while NMSettingClass
is only initialized during the class_init() method. Appart from that,
it's mostly a matter of taste, whether we attach meta data to
NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
by NMMetaSettingType.
Note, that previously, _nm_register_setting() was private API. That
means, no user could subclass a functioning NMSetting instance. The same
is still true: NMMetaSettingInfo is internal API and users cannot access
it to create their own NMSetting subclasses. But that is almost desired.
libnm is not designed, to be extensible via subclassing, nor is it
clear why that would be a useful thing to do. One day, we should remove
the NMSetting and NMSettingClass definitions from public headers. Their
only use is subclassing the types, which however does not work.
While libnm-core was linking already against nm-meta-setting.c,
nm_meta_setting_infos was unreferenced. So, this change increases
the binary size of libnm and NetworkManager (1032 bytes). Note however
that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingPriority _nm_setting_get_base_type_priority(NMSetting *setting);
|
|
|
|
|
int _nm_setting_compare_priority(gconstpointer a, gconstpointer b);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: use NMMetaSettingInfo for tracking setting priority
Previously, each (non abstract) NMSetting class had to register
its name and priority via _nm_register_setting().
Note, that libnm-core.la already links against "nm-meta-setting.c",
which also redundantly keeps track of the settings name and gtype
as well.
Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
data.
The goal is to get rid of private data structures that track
meta data about NMSetting classes. In this case, "registered_settings"
hash. Instead, we should have one place where all this meta data
is tracked. This was, it is also accessible as internal API,
which can be useful (for keyfile).
Note that NMSettingClass has some overlap with NMMetaSettingInfo.
One difference is, that NMMetaSettingInfo is const, while NMSettingClass
is only initialized during the class_init() method. Appart from that,
it's mostly a matter of taste, whether we attach meta data to
NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
by NMMetaSettingType.
Note, that previously, _nm_register_setting() was private API. That
means, no user could subclass a functioning NMSetting instance. The same
is still true: NMMetaSettingInfo is internal API and users cannot access
it to create their own NMSetting subclasses. But that is almost desired.
libnm is not designed, to be extensible via subclassing, nor is it
clear why that would be a useful thing to do. One day, we should remove
the NMSetting and NMSettingClass definitions from public headers. Their
only use is subclassing the types, which however does not work.
While libnm-core was linking already against nm-meta-setting.c,
nm_meta_setting_infos was unreferenced. So, this change increases
the binary size of libnm and NetworkManager (1032 bytes). Note however
that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
void _nm_setting_emit_property_changed(NMSetting *setting);
|
2019-01-20 13:49:08 +01:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
typedef enum NMSettingUpdateSecretResult {
|
2020-09-28 16:03:33 +02:00
|
|
|
NM_SETTING_UPDATE_SECRET_ERROR = FALSE,
|
|
|
|
|
NM_SETTING_UPDATE_SECRET_SUCCESS_MODIFIED = TRUE,
|
|
|
|
|
NM_SETTING_UPDATE_SECRET_SUCCESS_UNCHANGED = 2,
|
2014-07-24 08:53:33 -04:00
|
|
|
} NMSettingUpdateSecretResult;
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingUpdateSecretResult
|
|
|
|
|
_nm_setting_update_secrets(NMSetting *setting, GVariant *secrets, GError **error);
|
|
|
|
|
gboolean _nm_setting_clear_secrets(NMSetting * setting,
|
|
|
|
|
NMSettingClearSecretsWithFlagsFn func,
|
|
|
|
|
gpointer user_data);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/* The property of the #NMSetting should be considered during comparisons that
|
|
|
|
|
* use the %NM_SETTING_COMPARE_FLAG_INFERRABLE flag. Properties that don't have
|
|
|
|
|
* this flag, are ignored when doing an infrerrable comparison. This flag should
|
|
|
|
|
* be set on all properties that are read from the kernel or the system when a
|
|
|
|
|
* connection is generated. eg, IP addresses/routes can be read from the
|
|
|
|
|
* kernel, but the 'autoconnect' property cannot, so
|
|
|
|
|
* %NM_SETTING_IP4_CONFIG_ADDRESSES gets the INFERRABLE flag, but
|
|
|
|
|
* %NM_SETTING_CONNECTION_AUTOCONNECT would not.
|
|
|
|
|
*
|
|
|
|
|
* This flag should not be used with properties where the default cannot be
|
|
|
|
|
* read separately from the current value, like MTU or wired duplex mode.
|
|
|
|
|
*/
|
|
|
|
|
#define NM_SETTING_PARAM_INFERRABLE (1 << (4 + G_PARAM_USER_SHIFT))
|
|
|
|
|
|
2014-11-14 11:46:19 -05:00
|
|
|
/* This is a legacy property, which clients should not send to the daemon. */
|
|
|
|
|
#define NM_SETTING_PARAM_LEGACY (1 << (5 + G_PARAM_USER_SHIFT))
|
|
|
|
|
|
2015-09-18 17:21:34 +02:00
|
|
|
/* When a connection is active and gets modified, usually the change
|
|
|
|
|
* to the settings-connection does not propagate automatically to the
|
|
|
|
|
* applied-connection of the device. For certain properties like the
|
|
|
|
|
* firewall zone and the metered property, this is different.
|
|
|
|
|
*
|
|
|
|
|
* Such fields can be ignored during nm_connection_compare() with the
|
|
|
|
|
* NMSettingCompareFlag NM_SETTING_COMPARE_FLAG_IGNORE_REAPPLY_IMMEDIATELY.
|
|
|
|
|
*/
|
|
|
|
|
#define NM_SETTING_PARAM_REAPPLY_IMMEDIATELY (1 << (6 + G_PARAM_USER_SHIFT))
|
|
|
|
|
|
2019-09-24 18:25:00 +02:00
|
|
|
/* property_to_dbus() should ignore the property flags, and instead always calls to_dbus_fcn()
|
|
|
|
|
*/
|
|
|
|
|
#define NM_SETTING_PARAM_TO_DBUS_IGNORE_FLAGS (1 << (7 + G_PARAM_USER_SHIFT))
|
|
|
|
|
|
2019-09-22 10:57:57 +02:00
|
|
|
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_interface_name;
|
|
|
|
|
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_ignore_i;
|
|
|
|
|
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_ignore_u;
|
|
|
|
|
|
|
|
|
|
extern const NMSettInfoPropertType nm_sett_info_propert_type_plain_i;
|
|
|
|
|
extern const NMSettInfoPropertType nm_sett_info_propert_type_plain_u;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingVerifyResult
|
|
|
|
|
_nm_setting_verify(NMSetting *setting, NMConnection *connection, GError **error);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_verify_secret_string(const char *str,
|
|
|
|
|
const char *setting_name,
|
|
|
|
|
const char *property,
|
|
|
|
|
GError ** error);
|
2015-11-10 14:36:20 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_aggregate(NMSetting *setting, NMConnectionAggregateType type, gpointer arg);
|
2019-01-04 11:28:27 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_slave_type_is_valid(const char *slave_type, const char **out_port_type);
|
2014-07-07 17:05:10 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
GVariant *_nm_setting_to_dbus(NMSetting * setting,
|
|
|
|
|
NMConnection * connection,
|
|
|
|
|
NMConnectionSerializationFlags flags,
|
|
|
|
|
const NMConnectionSerializationOptions *options);
|
2014-08-04 11:23:11 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSetting *_nm_setting_new_from_dbus(GType setting_type,
|
|
|
|
|
GVariant * setting_dict,
|
|
|
|
|
GVariant * connection_dict,
|
|
|
|
|
NMSettingParseFlags parse_flags,
|
|
|
|
|
GError ** error);
|
libnm-core: add dbus-only properties to NMSettingClass
Add _nm_setting_class_add_dbus_only_property(), for declaring
properties that appear in the D-Bus serialization, but which don't
correspond to GObject properties.
Since some property overrides will require examining settings other
than the setting that they are on (eg, the value of
802-11-wireless.security depends on whether an
NMSettingWirelessSecurity setting is present, and
NMSettingConnection:interface-name might sometimes be set from, eg,
bond.interface-name), we also update _nm_setting_to_dbus() to take the
full NMConnection as an argument, and _nm_setting_new_from_dbus() to
take the full connection hash.
Additionally, with some deprecated properties, we'll want to validate
them on construction, but we don't need to keep the value around after
that. So allow _nm_setting_new_from_dbus() to return a verification
error directly, so we don't need to store the value until the verify()
call.
2014-07-29 18:25:10 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_property_is_regular_secret(NMSetting *setting, const char *secret_name);
|
|
|
|
|
gboolean _nm_setting_property_is_regular_secret_flags(NMSetting * setting,
|
|
|
|
|
const char *secret_flags_name);
|
2019-01-06 13:49:46 +01:00
|
|
|
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static inline GArray *
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_sett_info_property_override_create_array(void)
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return g_array_new(FALSE, FALSE, sizeof(NMSettInfoProperty));
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
GArray *_nm_sett_info_property_override_create_array_ip_config(void);
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
void _nm_setting_class_commit_full(NMSettingClass * setting_class,
|
|
|
|
|
NMMetaSettingType meta_type,
|
|
|
|
|
const NMSettInfoSettDetail *detail,
|
|
|
|
|
GArray * properties_override);
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
|
|
|
|
|
static inline void
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_setting_class_commit(NMSettingClass *setting_class, NMMetaSettingType meta_type)
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_setting_class_commit_full(setting_class, meta_type, NULL, NULL);
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#define NM_SETT_INFO_SETT_GENDATA(...) \
|
|
|
|
|
({ \
|
|
|
|
|
static const NMSettInfoSettGendata _g = {__VA_ARGS__}; \
|
|
|
|
|
\
|
|
|
|
|
&_g; \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
#define NM_SETT_INFO_SETT_DETAIL(...) (&((const NMSettInfoSettDetail){__VA_ARGS__}))
|
|
|
|
|
|
|
|
|
|
#define NM_SETT_INFO_PROPERT_TYPE(...) \
|
|
|
|
|
({ \
|
|
|
|
|
static const NMSettInfoPropertType _g = {__VA_ARGS__}; \
|
|
|
|
|
\
|
|
|
|
|
&_g; \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
#define NM_SETT_INFO_PROPERTY(...) (&((const NMSettInfoProperty){__VA_ARGS__}))
|
|
|
|
|
|
|
|
|
|
gboolean _nm_properties_override_assert(const NMSettInfoProperty *prop_info);
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
|
2019-09-22 15:23:41 +02:00
|
|
|
static inline void
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_properties_override(GArray *properties_override, const NMSettInfoProperty *prop_info)
|
2019-09-22 15:23:41 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_assert(properties_override);
|
|
|
|
|
nm_assert(_nm_properties_override_assert(prop_info));
|
|
|
|
|
g_array_append_vals(properties_override, prop_info, 1);
|
2019-09-22 15:23:41 +02:00
|
|
|
}
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
|
2019-09-22 15:32:04 +02:00
|
|
|
#define _nm_properties_override_gobj(properties_override, p_param_spec, p_property_type) \
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_properties_override( \
|
|
|
|
|
(properties_override), \
|
|
|
|
|
NM_SETT_INFO_PROPERTY(.param_spec = (p_param_spec), .property_type = (p_property_type), ))
|
2019-09-22 15:32:04 +02:00
|
|
|
|
|
|
|
|
#define _nm_properties_override_dbus(properties_override, p_name, p_property_type) \
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_properties_override( \
|
|
|
|
|
(properties_override), \
|
|
|
|
|
NM_SETT_INFO_PROPERTY(.name = ("" p_name ""), .property_type = (p_property_type), ))
|
2019-09-22 10:57:57 +02:00
|
|
|
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
/*****************************************************************************/
|
2014-07-30 10:46:24 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_use_legacy_property(NMSetting * setting,
|
|
|
|
|
GVariant * connection_dict,
|
|
|
|
|
const char *legacy_property,
|
|
|
|
|
const char *new_property);
|
2014-11-14 11:46:19 -05:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
GPtrArray *_nm_setting_need_secrets(NMSetting *setting);
|
2014-10-07 08:46:36 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
gboolean _nm_setting_should_compare_secret_property(NMSetting * setting,
|
|
|
|
|
NMSetting * other,
|
|
|
|
|
const char * secret_name,
|
|
|
|
|
NMSettingCompareFlags flags);
|
libnm: rework compare_property() implementation for NMSetting
NMSetting's compare_property() has and had two callers:
nm_setting_compare() and nm_setting_diff().
compare_property() accepts a NMSettingCompareFlags argument, but
at the same time, both callers have another complex (and
inconsistent!) set of pre-checks for shortcuting the call of
compare_property(): should_compare_prop().
Merge should_compare_prop() into compare_property(). This way,
nm_setting_compare() and nm_setting_diff() has less additional
code, and are simpler to follow. Especially nm_setting_compare()
is now trivial. And nm_setting_diff() is still complicated, but
not related to the question how the property compares or whether
it should be compared at all.
If you want to know whether it should be compared, all you need to do
now is follow NMSettingClass.compare_property().
This changes function pointer NMSettingClass.compare_property(),
which is public API. However, no user can actually use this (and shall
not!), because _nm_setting_class_commit_full() etc. is private API. A
user outside of libnm-core cannot create his/her own subclasses of
NMSetting, and never could in the past. So, this API/ABI change doesn't
matter.
2019-01-09 09:08:39 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
NMBridgeVlan *_nm_bridge_vlan_dup(const NMBridgeVlan *vlan);
|
|
|
|
|
NMBridgeVlan *_nm_bridge_vlan_dup_and_seal(const NMBridgeVlan *vlan);
|
2019-03-16 17:21:35 +01:00
|
|
|
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#endif /* NM_SETTING_PRIVATE_H */
|
