diff options
| author | Michael Biebl <biebl@debian.org> | 2018-09-23 10:10:27 +0200 |
|---|---|---|
| committer | Michael Biebl <biebl@debian.org> | 2018-09-23 10:10:27 +0200 |
| commit | e126f3e804c35480c4f075777430419d6ece23da (patch) | |
| tree | 5d5821ebcda8cd6ac34d2483bb3354910e508930 /shared/nm-meta-setting.h | |
| parent | c240974325c552cad177c457d6ff04e381fd77a3 (diff) | |
New upstream version 1.12.4 upstream/1.12.4
Diffstat (limited to 'shared/nm-meta-setting.h')
| -rw-r--r-- | shared/nm-meta-setting.h | 108 |
1 files changed, 9 insertions, 99 deletions
diff --git a/shared/nm-meta-setting.h b/shared/nm-meta-setting.h index 26c29bea..4333001b 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 - 2018 Red Hat, Inc. + * Copyright 2017 Red Hat, Inc. */ #ifndef __NM_META_SETTING_H__ @@ -26,47 +26,6 @@ /*****************************************************************************/ -/* - * 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, @@ -97,18 +56,7 @@ 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, @@ -118,16 +66,15 @@ 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_MATCH, + NM_META_SETTING_TYPE_OLPC_MESH, NM_META_SETTING_TYPE_OVS_BRIDGE, NM_META_SETTING_TYPE_OVS_INTERFACE, NM_META_SETTING_TYPE_OVS_PATCH, @@ -136,7 +83,6 @@ 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, @@ -146,57 +92,21 @@ typedef enum { NM_META_SETTING_TYPE_VPN, NM_META_SETTING_TYPE_VXLAN, NM_META_SETTING_TYPE_WIMAX, - NM_META_SETTING_TYPE_WPAN, + NM_META_SETTING_TYPE_WIRED, + NM_META_SETTING_TYPE_WIRELESS, + NM_META_SETTING_TYPE_WIRELESS_SECURITY, NM_META_SETTING_TYPE_UNKNOWN, _NM_META_SETTING_TYPE_NUM = NM_META_SETTING_TYPE_UNKNOWN, } NMMetaSettingType; -/* 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 { +typedef struct { + NMMetaSettingType meta_type; const char *setting_name; GType (*get_setting_gtype) (void); - NMMetaSettingType meta_type; - NMSettingPriority setting_priority; -}; +} NMMetaSettingInfo; -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); |