about summary refs log tree commit diff
path: root/shared/nm-meta-setting.h
diff options
context:
space:
mode:
authorMichael Biebl <biebl@debian.org>2018-09-08 17:44:06 +0200
committerMichael Biebl <biebl@debian.org>2018-09-08 17:44:06 +0200
commit8f7a3cbbdd0c0a48277c341dd3a8ec8743ae9735 (patch)
tree4353551fcb59cc822c3cadf2f4888f70601e8fbf /shared/nm-meta-setting.h
parentcaf1db9d6fbc056cc6c76a24574890f6c7895f3d (diff)
New upstream version 1.13.90 upstream/1.13.90
Diffstat (limited to 'shared/nm-meta-setting.h')
-rw-r--r--shared/nm-meta-setting.h108
1 files changed, 99 insertions, 9 deletions
diff --git a/shared/nm-meta-setting.h b/shared/nm-meta-setting.h
index 4333001b..26c29bea 100644
--- a/shared/nm-meta-setting.h
+++ b/shared/nm-meta-setting.h
@@ -16,7 +16,7 @@
  * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
  * Boston, MA 02110-1301 USA.
  *
- * Copyright 2017 Red Hat, Inc.
+ * Copyright 2017 - 2018 Red Hat, Inc.
  */
 
 #ifndef __NM_META_SETTING_H__
@@ -26,6 +26,47 @@
 
 /*****************************************************************************/
 
+/*
+ * A setting's priority should roughly follow the OSI layer model, but it also
+ * controls which settings get asked for secrets first.  Thus settings which
+ * relate to things that must be working first, like hardware, should get a
+ * higher priority than things which layer on top of the hardware.  For example,
+ * the GSM/CDMA settings should provide secrets before the PPP setting does,
+ * because a PIN is required to unlock the device before PPP can even start.
+ * Even settings without secrets should be assigned the right priority.
+ *
+ * 0: reserved for invalid
+ *
+ * 1: reserved for the Connection setting
+ *
+ * 2,3: hardware-related settings like Ethernet, Wi-Fi, InfiniBand, Bridge, etc.
+ * These priority 1 settings are also "base types", which means that at least
+ * one of them is required for the connection to be valid, and their name is
+ * valid in the 'type' property of the Connection setting.
+ *
+ * 4: hardware-related auxiliary settings that require a base setting to be
+ * successful first, like Wi-Fi security, 802.1x, etc.
+ *
+ * 5: hardware-independent settings that are required before IP connectivity
+ * can be established, like PPP, PPPoE, etc.
+ *
+ * 6: IP-level stuff
+ *
+ * 10: NMSettingUser
+ */
+typedef enum { /*< skip >*/
+	NM_SETTING_PRIORITY_INVALID     = 0,
+	NM_SETTING_PRIORITY_CONNECTION  = 1,
+	NM_SETTING_PRIORITY_HW_BASE     = 2,
+	NM_SETTING_PRIORITY_HW_NON_BASE = 3,
+	NM_SETTING_PRIORITY_HW_AUX      = 4,
+	NM_SETTING_PRIORITY_AUX         = 5,
+	NM_SETTING_PRIORITY_IP          = 6,
+	NM_SETTING_PRIORITY_USER        = 10,
+} NMSettingPriority;
+
+/*****************************************************************************/
+
 typedef enum {
 	NM_SETTING_802_1X_SCHEME_TYPE_CA_CERT,
 	NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CA_CERT,
@@ -56,7 +97,18 @@ extern const NMSetting8021xSchemeVtable nm_setting_8021x_scheme_vtable[_NM_SETTI
 /*****************************************************************************/
 
 typedef enum {
+	/* the enum (and their numeric values) are internal API. Do not assign
+	 * any meaning the numeric values, because they already have one:
+	 *
+	 * they are sorted in a way, that corresponds to the asciibetical sort
+	 * order of the corresponding setting-name. */
+
+	NM_META_SETTING_TYPE_6LOWPAN,
+	NM_META_SETTING_TYPE_OLPC_MESH,
+	NM_META_SETTING_TYPE_WIRELESS,
+	NM_META_SETTING_TYPE_WIRELESS_SECURITY,
 	NM_META_SETTING_TYPE_802_1X,
+	NM_META_SETTING_TYPE_WIRED,
 	NM_META_SETTING_TYPE_ADSL,
 	NM_META_SETTING_TYPE_BLUETOOTH,
 	NM_META_SETTING_TYPE_BOND,
@@ -66,15 +118,16 @@ typedef enum {
 	NM_META_SETTING_TYPE_CONNECTION,
 	NM_META_SETTING_TYPE_DCB,
 	NM_META_SETTING_TYPE_DUMMY,
+	NM_META_SETTING_TYPE_ETHTOOL,
 	NM_META_SETTING_TYPE_GENERIC,
 	NM_META_SETTING_TYPE_GSM,
 	NM_META_SETTING_TYPE_INFINIBAND,
+	NM_META_SETTING_TYPE_IP_TUNNEL,
 	NM_META_SETTING_TYPE_IP4_CONFIG,
 	NM_META_SETTING_TYPE_IP6_CONFIG,
-	NM_META_SETTING_TYPE_IP_TUNNEL,
 	NM_META_SETTING_TYPE_MACSEC,
 	NM_META_SETTING_TYPE_MACVLAN,
-	NM_META_SETTING_TYPE_OLPC_MESH,
+	NM_META_SETTING_TYPE_MATCH,
 	NM_META_SETTING_TYPE_OVS_BRIDGE,
 	NM_META_SETTING_TYPE_OVS_INTERFACE,
 	NM_META_SETTING_TYPE_OVS_PATCH,
@@ -83,6 +136,7 @@ typedef enum {
 	NM_META_SETTING_TYPE_PPPOE,
 	NM_META_SETTING_TYPE_PROXY,
 	NM_META_SETTING_TYPE_SERIAL,
+	NM_META_SETTING_TYPE_SRIOV,
 	NM_META_SETTING_TYPE_TC_CONFIG,
 	NM_META_SETTING_TYPE_TEAM,
 	NM_META_SETTING_TYPE_TEAM_PORT,
@@ -92,21 +146,57 @@ typedef enum {
 	NM_META_SETTING_TYPE_VPN,
 	NM_META_SETTING_TYPE_VXLAN,
 	NM_META_SETTING_TYPE_WIMAX,
-	NM_META_SETTING_TYPE_WIRED,
-	NM_META_SETTING_TYPE_WIRELESS,
-	NM_META_SETTING_TYPE_WIRELESS_SECURITY,
+	NM_META_SETTING_TYPE_WPAN,
 
 	NM_META_SETTING_TYPE_UNKNOWN,
 
 	_NM_META_SETTING_TYPE_NUM = NM_META_SETTING_TYPE_UNKNOWN,
 } NMMetaSettingType;
 
-typedef struct {
-	NMMetaSettingType meta_type;
+/* this header is statically linked with both libnm-core.la and libnmc.la.
+ * Though, there is no stable API/ABI, so whenever on of these components
+ * accesses NMMetaSettingInfo or NMMetaSettingType, it only has meaning
+ * inside the same component.
+ *
+ * Note how NMSettingClass has field of type "struct _NMMetaSettingInfo".
+ * It would be a serious bug, if libnmc tries to interpret this pointer
+ * with the meaning of NMMetaSettingInfo. They might be different, because
+ * libnm.so (libnm-core.la) might be a newer version than nmcli (libnmc.la).
+ *
+ * This define helps to ensure that we don't accidentally use the pointer
+ * in different contexts. */
+#if ((NETWORKMANAGER_COMPILATION) & NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_INTERNAL)
+#define _NMMetaSettingInfoXX _NMMetaSettingInfo
+#else
+#define _NMMetaSettingInfoXX _NMMetaSettingInfoCli
+#endif
+struct _NMMetaSettingInfoXX {
 	const char *setting_name;
 	GType (*get_setting_gtype) (void);
-} NMMetaSettingInfo;
+	NMMetaSettingType meta_type;
+	NMSettingPriority setting_priority;
+};
 
+typedef struct _NMMetaSettingInfoXX NMMetaSettingInfo;
+
+/* note that we statically link nm-meta-setting.h both to libnm-core.la and
+ * libnmc.la. That means, there are two versions of nm_meta_setting_infos
+ * in nmcli. That is not easily avoidable, because at this point, we don't
+ * want yet to making it public API.
+ *
+ * Eventually, this should become public API of libnm, and nmcli/libnmc.la
+ * should use that version.
+ *
+ * Downsides of the current solution:
+ *
+ * - duplication of the array in nmcli.
+ *
+ * - there is no stable API/ABI. That means, when you have a NMMetaSettingInfo
+ *   pointer, or a NMMetaSettingType value, the value can only be used within
+ *   the current context (libnm-core.la or libnmc.la). In other words, libnmc.la
+ *   (and nmcli) must never access a NMMetaSettingInfo/NMMetaSettingType value,
+ *   that comes from libnm-core.la.
+ */
 extern const NMMetaSettingInfo nm_meta_setting_infos[_NM_META_SETTING_TYPE_NUM + 1];
 
 const NMMetaSettingInfo *nm_meta_setting_infos_by_name (const char *name);