2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2017-02-17 17:10:44 +01:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2017 - 2018 Red Hat, Inc.
|
2017-02-17 17:10:44 +01:00
|
|
|
*/
|
|
|
|
|
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
#ifndef __NM_META_SETTING_BASE_IMPL_H__
|
|
|
|
|
#define __NM_META_SETTING_BASE_IMPL_H__
|
2017-02-17 17:10:44 +01:00
|
|
|
|
2017-02-17 17:16:38 +01:00
|
|
|
#include "nm-setting-8021x.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
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
typedef enum {
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_CA_CERT,
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CA_CERT,
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_CLIENT_CERT,
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CLIENT_CERT,
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_PRIVATE_KEY,
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_PRIVATE_KEY,
|
|
|
|
|
|
|
|
|
|
NM_SETTING_802_1X_SCHEME_TYPE_UNKNOWN,
|
|
|
|
|
|
|
|
|
|
_NM_SETTING_802_1X_SCHEME_TYPE_NUM = NM_SETTING_802_1X_SCHEME_TYPE_UNKNOWN,
|
|
|
|
|
} NMSetting8021xSchemeType;
|
|
|
|
|
|
2017-02-17 17:16:38 +01:00
|
|
|
typedef struct {
|
|
|
|
|
const char *setting_key;
|
|
|
|
|
NMSetting8021xCKScheme (*scheme_func)(NMSetting8021x *setting);
|
|
|
|
|
NMSetting8021xCKFormat (*format_func)(NMSetting8021x *setting);
|
|
|
|
|
const char *(*path_func)(NMSetting8021x *setting);
|
|
|
|
|
GBytes *(*blob_func)(NMSetting8021x *setting);
|
|
|
|
|
const char *(*uri_func)(NMSetting8021x *setting);
|
|
|
|
|
const char *(*passwd_func)(NMSetting8021x *setting);
|
|
|
|
|
NMSettingSecretFlags (*pwflag_func)(NMSetting8021x *setting);
|
2019-03-19 10:22:26 +01:00
|
|
|
gboolean (*set_cert_func)(NMSetting8021x * setting,
|
|
|
|
|
const char * value,
|
|
|
|
|
NMSetting8021xCKScheme scheme,
|
|
|
|
|
NMSetting8021xCKFormat *out_format,
|
|
|
|
|
GError ** error);
|
|
|
|
|
gboolean (*set_private_key_func)(NMSetting8021x * setting,
|
|
|
|
|
const char * value,
|
|
|
|
|
const char * password,
|
|
|
|
|
NMSetting8021xCKScheme scheme,
|
|
|
|
|
NMSetting8021xCKFormat *out_format,
|
|
|
|
|
GError ** error);
|
2017-02-17 17:16:38 +01:00
|
|
|
const char * file_suffix;
|
2019-05-15 09:45:55 +02:00
|
|
|
NMSetting8021xSchemeType scheme_type;
|
2019-03-19 10:22:26 +01:00
|
|
|
bool is_secret : 1;
|
2017-02-17 17:16:38 +01:00
|
|
|
} NMSetting8021xSchemeVtable;
|
|
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
extern const NMSetting8021xSchemeVtable
|
|
|
|
|
nm_setting_8021x_scheme_vtable[_NM_SETTING_802_1X_SCHEME_TYPE_NUM + 1];
|
2017-02-17 17:16:38 +01:00
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
typedef enum {
|
2018-07-28 12:56:57 +02:00
|
|
|
/* 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. */
|
|
|
|
|
|
2018-05-22 17:11:30 +02:00
|
|
|
NM_META_SETTING_TYPE_6LOWPAN,
|
2018-07-28 12:56:57 +02:00
|
|
|
NM_META_SETTING_TYPE_OLPC_MESH,
|
|
|
|
|
NM_META_SETTING_TYPE_WIRELESS,
|
|
|
|
|
NM_META_SETTING_TYPE_WIRELESS_SECURITY,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_802_1X,
|
2018-07-28 12:56:57 +02:00
|
|
|
NM_META_SETTING_TYPE_WIRED,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_ADSL,
|
|
|
|
|
NM_META_SETTING_TYPE_BLUETOOTH,
|
|
|
|
|
NM_META_SETTING_TYPE_BOND,
|
|
|
|
|
NM_META_SETTING_TYPE_BRIDGE,
|
|
|
|
|
NM_META_SETTING_TYPE_BRIDGE_PORT,
|
|
|
|
|
NM_META_SETTING_TYPE_CDMA,
|
|
|
|
|
NM_META_SETTING_TYPE_CONNECTION,
|
|
|
|
|
NM_META_SETTING_TYPE_DCB,
|
2017-03-26 14:30:17 +02:00
|
|
|
NM_META_SETTING_TYPE_DUMMY,
|
libnm, cli, ifcfg-rh: add NMSettingEthtool setting
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
2018-07-16 23:37:55 +02:00
|
|
|
NM_META_SETTING_TYPE_ETHTOOL,
|
2017-04-10 21:40:19 +02:00
|
|
|
NM_META_SETTING_TYPE_GENERIC,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_GSM,
|
2020-10-31 10:50:56 +01:00
|
|
|
NM_META_SETTING_TYPE_HOSTNAME,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_INFINIBAND,
|
2018-07-28 12:56:57 +02:00
|
|
|
NM_META_SETTING_TYPE_IP_TUNNEL,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_IP4_CONFIG,
|
|
|
|
|
NM_META_SETTING_TYPE_IP6_CONFIG,
|
|
|
|
|
NM_META_SETTING_TYPE_MACSEC,
|
|
|
|
|
NM_META_SETTING_TYPE_MACVLAN,
|
2018-08-07 15:52:56 +02:00
|
|
|
NM_META_SETTING_TYPE_MATCH,
|
2017-08-01 20:28:05 +02:00
|
|
|
NM_META_SETTING_TYPE_OVS_BRIDGE,
|
2019-06-11 15:53:05 +02:00
|
|
|
NM_META_SETTING_TYPE_OVS_DPDK,
|
2020-11-02 17:29:26 +01:00
|
|
|
NM_META_SETTING_TYPE_OVS_EXTERNAL_IDS,
|
2017-08-01 20:28:05 +02:00
|
|
|
NM_META_SETTING_TYPE_OVS_INTERFACE,
|
2017-08-01 20:28:05 +02:00
|
|
|
NM_META_SETTING_TYPE_OVS_PATCH,
|
2017-08-01 20:28:05 +02:00
|
|
|
NM_META_SETTING_TYPE_OVS_PORT,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_PPP,
|
|
|
|
|
NM_META_SETTING_TYPE_PPPOE,
|
|
|
|
|
NM_META_SETTING_TYPE_PROXY,
|
|
|
|
|
NM_META_SETTING_TYPE_SERIAL,
|
2018-05-24 17:48:37 +02:00
|
|
|
NM_META_SETTING_TYPE_SRIOV,
|
2017-11-16 19:19:37 +01:00
|
|
|
NM_META_SETTING_TYPE_TC_CONFIG,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_TEAM,
|
|
|
|
|
NM_META_SETTING_TYPE_TEAM_PORT,
|
|
|
|
|
NM_META_SETTING_TYPE_TUN,
|
|
|
|
|
NM_META_SETTING_TYPE_USER,
|
2020-11-12 21:58:13 +01:00
|
|
|
NM_META_SETTING_TYPE_VETH,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_VLAN,
|
|
|
|
|
NM_META_SETTING_TYPE_VPN,
|
2019-12-05 10:13:34 +01:00
|
|
|
NM_META_SETTING_TYPE_VRF,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_VXLAN,
|
2019-01-28 15:21:59 +01:00
|
|
|
NM_META_SETTING_TYPE_WIFI_P2P,
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_WIMAX,
|
2018-12-27 16:48:30 +01:00
|
|
|
NM_META_SETTING_TYPE_WIREGUARD,
|
2018-03-09 18:21:10 +01:00
|
|
|
NM_META_SETTING_TYPE_WPAN,
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
NM_META_SETTING_TYPE_UNKNOWN,
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
_NM_META_SETTING_TYPE_NUM = NM_META_SETTING_TYPE_UNKNOWN,
|
|
|
|
|
} NMMetaSettingType;
|
|
|
|
|
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
#if _NM_META_SETTING_BASE_IMPL_LIBNM
|
|
|
|
|
#define _NMMetaSettingInfo_Alias _NMMetaSettingInfo
|
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
|
|
|
#else
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
#define _NMMetaSettingInfo_Alias _NMMetaSettingInfoCli
|
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
|
|
|
#endif
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
|
|
|
|
|
struct _NMMetaSettingInfo_Alias {
|
2017-03-24 15:55:19 +01:00
|
|
|
const char *setting_name;
|
|
|
|
|
GType (*get_setting_gtype)(void);
|
2018-07-28 12:56:57 +02:00
|
|
|
NMMetaSettingType meta_type;
|
|
|
|
|
NMSettingPriority setting_priority;
|
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
|
|
|
};
|
|
|
|
|
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
typedef struct _NMMetaSettingInfo_Alias NMMetaSettingInfo;
|
2017-03-24 15:55:19 +01:00
|
|
|
|
|
|
|
|
extern const NMMetaSettingInfo nm_meta_setting_infos[_NM_META_SETTING_TYPE_NUM + 1];
|
2017-02-17 17:16:38 +01:00
|
|
|
|
2017-03-24 15:55:19 +01:00
|
|
|
const NMMetaSettingInfo *nm_meta_setting_infos_by_name(const char *name);
|
|
|
|
|
const NMMetaSettingInfo *nm_meta_setting_infos_by_gtype(GType gtype);
|
2017-02-17 17:16:38 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2020-11-16 09:50:27 +01:00
|
|
|
NMSettingPriority nm_meta_setting_info_get_base_type_priority(const NMMetaSettingInfo *setting_info,
|
|
|
|
|
GType gtype);
|
|
|
|
|
NMSettingPriority _nm_setting_type_get_base_type_priority(GType type);
|
|
|
|
|
|
all: move shared/nm-meta-setting.[hc] to libnm-core and clients
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
2021-02-07 10:53:44 +01:00
|
|
|
#endif /* __NM_META_SETTING_BASE_IMPL_H__ */
|