fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-21 22:40:06 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/shared/nm-meta-setting.c

550 lines
22 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: LGPL-2.1+
all: add new "shared/nm-setting-metadata.h" file "shared/nm-setting-metadata.h" will contain data structures to handle NM setting properties in a generic way. For now, this is internal API, but shared between libnm-core (which extends to libnm, NetworkManager, device-plugins, settings-plugins), and nmcli. Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
2017-02-17 17:10:44 +01:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2017 - 2018 Red Hat, Inc.
all: add new "shared/nm-setting-metadata.h" file "shared/nm-setting-metadata.h" will contain data structures to handle NM setting properties in a generic way. For now, this is internal API, but shared between libnm-core (which extends to libnm, NetworkManager, device-plugins, settings-plugins), and nmcli. Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
2017-02-17 17:10:44 +01:00
*/
#include "nm-default.h"
cli: split nm-meta-setting-desc out of settings This part contains static functions and variables to describe settings. It is distinct from the mechanism to use them, or access them. Split it out. It still uses clients/cli/common.h and clients/cli/utils.h which shall be fixed next.
2017-03-28 11:38:00 +02:00
#include "nm-meta-setting.h"
all: add new "shared/nm-setting-metadata.h" file "shared/nm-setting-metadata.h" will contain data structures to handle NM setting properties in a generic way. For now, this is internal API, but shared between libnm-core (which extends to libnm, NetworkManager, device-plugins, settings-plugins), and nmcli. Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
2017-02-17 17:10:44 +01:00
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
#include "nm-setting-6lowpan.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-8021x.h"
#include "nm-setting-adsl.h"
#include "nm-setting-bluetooth.h"
#include "nm-setting-bond.h"
#include "nm-setting-bridge-port.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-setting-bridge.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-cdma.h"
#include "nm-setting-connection.h"
#include "nm-setting-dcb.h"
#include "nm-setting-dummy.h"
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
#include "nm-setting-ethtool.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-generic.h"
#include "nm-setting-gsm.h"
#include "nm-setting-infiniband.h"
#include "nm-setting-ip-config.h"
#include "nm-setting-ip-tunnel.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-setting-ip4-config.h"
#include "nm-setting-ip6-config.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-macsec.h"
#include "nm-setting-macvlan.h"
all: add 'match' setting Add a new 'match' setting containing properties to match a connection to devices. At the moment only the interface-name property is present and, contrary to connection.interface-name, it allows the use of wildcards.
2018-08-07 15:52:56 +02:00
#include "nm-setting-match.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-olpc-mesh.h"
clients: add support for ovs-bridge setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-bridge.h"
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-interface.h"
libnm-core: add ovs-dpdk setting
2019-06-11 15:53:05 +02:00
#include "nm-setting-ovs-dpdk.h"
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-patch.h"
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-port.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-ppp.h"
#include "nm-setting-pppoe.h"
#include "nm-setting-proxy.h"
#include "nm-setting-serial.h"
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
#include "nm-setting-tc-config.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-team-port.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-setting-team.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-tun.h"
#include "nm-setting-user.h"
#include "nm-setting-vlan.h"
#include "nm-setting-vpn.h"
libnm-core,cli: add VRF setting Add new VRF setting and connection types to libnm-core and support them in nmcli.
2019-12-05 10:13:34 +01:00
#include "nm-setting-vrf.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-vxlan.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-setting-wifi-p2p.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-wimax.h"
#include "nm-setting-wired.h"
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
#include "nm-setting-wireguard.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-wireless-security.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-setting-wireless.h"
client: support wpan setting
2018-03-09 18:21:10 +01:00
#include "nm-setting-wpan.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
/*****************************************************************************/
const NMSetting8021xSchemeVtable nm_setting_8021x_scheme_vtable[] = {
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
#define _D(_scheme_type, ...) \
[(_scheme_type)] = { \
.scheme_type = (_scheme_type), \
__VA_ARGS__ \
}
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
_D (NM_SETTING_802_1X_SCHEME_TYPE_UNKNOWN),
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
_D (NM_SETTING_802_1X_SCHEME_TYPE_CA_CERT,
.setting_key = NM_SETTING_802_1X_CA_CERT,
.scheme_func = nm_setting_802_1x_get_ca_cert_scheme,
.format_func = NULL,
.path_func = nm_setting_802_1x_get_ca_cert_path,
.blob_func = nm_setting_802_1x_get_ca_cert_blob,
.uri_func = nm_setting_802_1x_get_ca_cert_uri,
.passwd_func = nm_setting_802_1x_get_ca_cert_password,
.pwflag_func = nm_setting_802_1x_get_ca_cert_password_flags,
.set_cert_func = nm_setting_802_1x_set_ca_cert,
.file_suffix = "ca-cert",
),
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
_D (NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CA_CERT,
.setting_key = NM_SETTING_802_1X_PHASE2_CA_CERT,
.scheme_func = nm_setting_802_1x_get_phase2_ca_cert_scheme,
.format_func = NULL,
.path_func = nm_setting_802_1x_get_phase2_ca_cert_path,
.blob_func = nm_setting_802_1x_get_phase2_ca_cert_blob,
.uri_func = nm_setting_802_1x_get_phase2_ca_cert_uri,
.passwd_func = nm_setting_802_1x_get_phase2_ca_cert_password,
.pwflag_func = nm_setting_802_1x_get_phase2_ca_cert_password_flags,
.set_cert_func = nm_setting_802_1x_set_phase2_ca_cert,
.file_suffix = "inner-ca-cert",
),
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
_D (NM_SETTING_802_1X_SCHEME_TYPE_CLIENT_CERT,
.setting_key = NM_SETTING_802_1X_CLIENT_CERT,
.scheme_func = nm_setting_802_1x_get_client_cert_scheme,
.format_func = NULL,
.path_func = nm_setting_802_1x_get_client_cert_path,
.blob_func = nm_setting_802_1x_get_client_cert_blob,
.uri_func = nm_setting_802_1x_get_client_cert_uri,
.passwd_func = nm_setting_802_1x_get_client_cert_password,
.pwflag_func = nm_setting_802_1x_get_client_cert_password_flags,
.set_cert_func = nm_setting_802_1x_set_client_cert,
.file_suffix = "client-cert",
),
_D (NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CLIENT_CERT,
.setting_key = NM_SETTING_802_1X_PHASE2_CLIENT_CERT,
.scheme_func = nm_setting_802_1x_get_phase2_client_cert_scheme,
.format_func = NULL,
.path_func = nm_setting_802_1x_get_phase2_client_cert_path,
.blob_func = nm_setting_802_1x_get_phase2_client_cert_blob,
.uri_func = nm_setting_802_1x_get_phase2_client_cert_uri,
.passwd_func = nm_setting_802_1x_get_phase2_client_cert_password,
.pwflag_func = nm_setting_802_1x_get_phase2_client_cert_password_flags,
.set_cert_func = nm_setting_802_1x_set_phase2_client_cert,
.file_suffix = "inner-client-cert",
),
_D (NM_SETTING_802_1X_SCHEME_TYPE_PRIVATE_KEY,
.setting_key = NM_SETTING_802_1X_PRIVATE_KEY,
.scheme_func = nm_setting_802_1x_get_private_key_scheme,
.format_func = nm_setting_802_1x_get_private_key_format,
.path_func = nm_setting_802_1x_get_private_key_path,
.blob_func = nm_setting_802_1x_get_private_key_blob,
.uri_func = nm_setting_802_1x_get_private_key_uri,
.passwd_func = nm_setting_802_1x_get_private_key_password,
.pwflag_func = nm_setting_802_1x_get_private_key_password_flags,
.set_private_key_func = nm_setting_802_1x_set_private_key,
.file_suffix = "private-key",
.is_secret = TRUE,
),
_D (NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_PRIVATE_KEY,
.setting_key = NM_SETTING_802_1X_PHASE2_PRIVATE_KEY,
.scheme_func = nm_setting_802_1x_get_phase2_private_key_scheme,
.format_func = nm_setting_802_1x_get_phase2_private_key_format,
.path_func = nm_setting_802_1x_get_phase2_private_key_path,
.blob_func = nm_setting_802_1x_get_phase2_private_key_blob,
.uri_func = nm_setting_802_1x_get_phase2_private_key_uri,
.passwd_func = nm_setting_802_1x_get_phase2_private_key_password,
.pwflag_func = nm_setting_802_1x_get_phase2_private_key_password_flags,
.set_private_key_func = nm_setting_802_1x_set_phase2_private_key,
.file_suffix = "inner-private-key",
.is_secret = TRUE,
),
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
shared: embed scheme_type in NMSetting8021xSchemeVtable Since we can easily lookup the vtable for a NMSetting8021xSchemeType, it is convenient to also easily get the scheme_type for a given NMSetting8021xSchemeVtable. On my x86_64, this change is basically for free as it does not increase the size of NMSetting8021xSchemeVtable, because the scheme_type fits in a previously unused part of the NMSetting8021xSchemeVtable struct.
2019-05-15 09:45:55 +02:00
#undef _D
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
};
/*****************************************************************************/
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
const NMMetaSettingInfo nm_meta_setting_infos[] = {
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
[NM_META_SETTING_TYPE_6LOWPAN] = {
.meta_type = NM_META_SETTING_TYPE_6LOWPAN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
.setting_name = NM_SETTING_6LOWPAN_SETTING_NAME,
.get_setting_gtype = nm_setting_6lowpan_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_802_1X] = {
.meta_type = NM_META_SETTING_TYPE_802_1X,
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
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_802_1X_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_802_1x_get_type,
},
[NM_META_SETTING_TYPE_ADSL] = {
.meta_type = NM_META_SETTING_TYPE_ADSL,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_ADSL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_adsl_get_type,
},
[NM_META_SETTING_TYPE_BLUETOOTH] = {
.meta_type = NM_META_SETTING_TYPE_BLUETOOTH,
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
.setting_priority = NM_SETTING_PRIORITY_HW_NON_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BLUETOOTH_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bluetooth_get_type,
},
[NM_META_SETTING_TYPE_BOND] = {
.meta_type = NM_META_SETTING_TYPE_BOND,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BOND_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bond_get_type,
},
[NM_META_SETTING_TYPE_BRIDGE] = {
.meta_type = NM_META_SETTING_TYPE_BRIDGE,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BRIDGE_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bridge_get_type,
},
[NM_META_SETTING_TYPE_BRIDGE_PORT] = {
.meta_type = NM_META_SETTING_TYPE_BRIDGE_PORT,
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
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BRIDGE_PORT_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bridge_port_get_type,
},
[NM_META_SETTING_TYPE_CDMA] = {
.meta_type = NM_META_SETTING_TYPE_CDMA,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_CDMA_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_cdma_get_type,
},
[NM_META_SETTING_TYPE_CONNECTION] = {
.meta_type = NM_META_SETTING_TYPE_CONNECTION,
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
.setting_priority = NM_SETTING_PRIORITY_CONNECTION,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_CONNECTION_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_connection_get_type,
},
[NM_META_SETTING_TYPE_DCB] = {
.meta_type = NM_META_SETTING_TYPE_DCB,
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
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_DCB_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_dcb_get_type,
},
cli: add property-info for the rest
2017-03-26 14:30:17 +02:00
[NM_META_SETTING_TYPE_DUMMY] = {
.meta_type = NM_META_SETTING_TYPE_DUMMY,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_DUMMY_SETTING_NAME,
cli: add property-info for the rest
2017-03-26 14:30:17 +02:00
.get_setting_gtype = nm_setting_dummy_get_type,
},
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] = {
.meta_type = NM_META_SETTING_TYPE_ETHTOOL,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_ETHTOOL_SETTING_NAME,
.get_setting_gtype = nm_setting_ethtool_get_type,
},
cli: add meta data for NMSettingGeneric
2017-04-10 21:40:19 +02:00
[NM_META_SETTING_TYPE_GENERIC] = {
.meta_type = NM_META_SETTING_TYPE_GENERIC,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_GENERIC_SETTING_NAME,
cli: add meta data for NMSettingGeneric
2017-04-10 21:40:19 +02:00
.get_setting_gtype = nm_setting_generic_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_GSM] = {
.meta_type = NM_META_SETTING_TYPE_GSM,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_GSM_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_gsm_get_type,
},
[NM_META_SETTING_TYPE_INFINIBAND] = {
.meta_type = NM_META_SETTING_TYPE_INFINIBAND,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_INFINIBAND_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_infiniband_get_type,
},
[NM_META_SETTING_TYPE_IP4_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_IP4_CONFIG,
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
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP4_CONFIG_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip4_config_get_type,
},
[NM_META_SETTING_TYPE_IP6_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_IP6_CONFIG,
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
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP6_CONFIG_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip6_config_get_type,
},
[NM_META_SETTING_TYPE_IP_TUNNEL] = {
.meta_type = NM_META_SETTING_TYPE_IP_TUNNEL,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP_TUNNEL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip_tunnel_get_type,
},
[NM_META_SETTING_TYPE_MACSEC] = {
.meta_type = NM_META_SETTING_TYPE_MACSEC,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_MACSEC_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_macsec_get_type,
},
[NM_META_SETTING_TYPE_MACVLAN] = {
.meta_type = NM_META_SETTING_TYPE_MACVLAN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_MACVLAN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_macvlan_get_type,
},
all: add 'match' setting Add a new 'match' setting containing properties to match a connection to devices. At the moment only the interface-name property is present and, contrary to connection.interface-name, it allows the use of wildcards.
2018-08-07 15:52:56 +02:00
[NM_META_SETTING_TYPE_MATCH] = {
.meta_type = NM_META_SETTING_TYPE_MATCH,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_MATCH_SETTING_NAME,
.get_setting_gtype = nm_setting_match_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_OLPC_MESH] = {
.meta_type = NM_META_SETTING_TYPE_OLPC_MESH,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_OLPC_MESH_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_olpc_mesh_get_type,
},
clients: add support for ovs-bridge setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_BRIDGE] = {
.meta_type = NM_META_SETTING_TYPE_OVS_BRIDGE,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-bridge setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_BRIDGE_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_bridge_get_type,
},
libnm-core: add ovs-dpdk setting
2019-06-11 15:53:05 +02:00
[NM_META_SETTING_TYPE_OVS_DPDK] = {
.meta_type = NM_META_SETTING_TYPE_OVS_DPDK,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_OVS_DPDK_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_dpdk_get_type,
},
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_INTERFACE] = {
.meta_type = NM_META_SETTING_TYPE_OVS_INTERFACE,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_INTERFACE_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_interface_get_type,
},
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_PATCH] = {
.meta_type = NM_META_SETTING_TYPE_OVS_PATCH,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_PATCH_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_patch_get_type,
},
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_PORT] = {
.meta_type = NM_META_SETTING_TYPE_OVS_PORT,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_PORT_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_port_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_PPPOE] = {
.meta_type = NM_META_SETTING_TYPE_PPPOE,
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
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PPPOE_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_pppoe_get_type,
},
[NM_META_SETTING_TYPE_PPP] = {
.meta_type = NM_META_SETTING_TYPE_PPP,
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
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PPP_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ppp_get_type,
},
[NM_META_SETTING_TYPE_PROXY] = {
.meta_type = NM_META_SETTING_TYPE_PROXY,
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
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PROXY_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_proxy_get_type,
},
[NM_META_SETTING_TYPE_SERIAL] = {
.meta_type = NM_META_SETTING_TYPE_SERIAL,
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
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_SERIAL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_serial_get_type,
},
cli: add support for configuring SR-IOV
2018-05-24 17:48:37 +02:00
[NM_META_SETTING_TYPE_SRIOV] = {
.meta_type = NM_META_SETTING_TYPE_SRIOV,
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
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: add support for configuring SR-IOV
2018-05-24 17:48:37 +02:00
.setting_name = NM_SETTING_SRIOV_SETTING_NAME,
.get_setting_gtype = nm_setting_sriov_get_type,
},
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
[NM_META_SETTING_TYPE_TC_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_TC_CONFIG,
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
.setting_priority = NM_SETTING_PRIORITY_IP,
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
.setting_name = NM_SETTING_TC_CONFIG_SETTING_NAME,
.get_setting_gtype = nm_setting_tc_config_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_TEAM] = {
.meta_type = NM_META_SETTING_TYPE_TEAM,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TEAM_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_team_get_type,
},
[NM_META_SETTING_TYPE_TEAM_PORT] = {
.meta_type = NM_META_SETTING_TYPE_TEAM_PORT,
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
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TEAM_PORT_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_team_port_get_type,
},
[NM_META_SETTING_TYPE_TUN] = {
.meta_type = NM_META_SETTING_TYPE_TUN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TUN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_tun_get_type,
},
[NM_META_SETTING_TYPE_USER] = {
.meta_type = NM_META_SETTING_TYPE_USER,
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
.setting_priority = NM_SETTING_PRIORITY_USER,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_USER_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_user_get_type,
},
[NM_META_SETTING_TYPE_VLAN] = {
.meta_type = NM_META_SETTING_TYPE_VLAN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_VLAN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_vlan_get_type,
},
[NM_META_SETTING_TYPE_VPN] = {
.meta_type = NM_META_SETTING_TYPE_VPN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_VPN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_vpn_get_type,
},
libnm-core,cli: add VRF setting Add new VRF setting and connection types to libnm-core and support them in nmcli.
2019-12-05 10:13:34 +01:00
[NM_META_SETTING_TYPE_VRF] = {
.meta_type = NM_META_SETTING_TYPE_VRF,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_VRF_SETTING_NAME,
.get_setting_gtype = nm_setting_vrf_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_VXLAN] = {
.meta_type = NM_META_SETTING_TYPE_VXLAN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_VXLAN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_vxlan_get_type,
},
wifi-p2p: rename Wi-Fi P2P After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
2019-01-28 15:21:59 +01:00
[NM_META_SETTING_TYPE_WIFI_P2P] = {
.meta_type = NM_META_SETTING_TYPE_WIFI_P2P,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_WIFI_P2P_SETTING_NAME,
.get_setting_gtype = nm_setting_wifi_p2p_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_WIMAX] = {
.meta_type = NM_META_SETTING_TYPE_WIMAX,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIMAX_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wimax_get_type,
},
[NM_META_SETTING_TYPE_WIRED] = {
.meta_type = NM_META_SETTING_TYPE_WIRED,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIRED_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wired_get_type,
},
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
[NM_META_SETTING_TYPE_WIREGUARD] = {
.meta_type = NM_META_SETTING_TYPE_WIREGUARD,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_WIREGUARD_SETTING_NAME,
.get_setting_gtype = nm_setting_wireguard_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_WIRELESS] = {
.meta_type = NM_META_SETTING_TYPE_WIRELESS,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIRELESS_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wireless_get_type,
},
[NM_META_SETTING_TYPE_WIRELESS_SECURITY] = {
.meta_type = NM_META_SETTING_TYPE_WIRELESS_SECURITY,
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
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIRELESS_SECURITY_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wireless_security_get_type,
},
client: support wpan setting
2018-03-09 18:21:10 +01:00
[NM_META_SETTING_TYPE_WPAN] = {
.meta_type = NM_META_SETTING_TYPE_WPAN,
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
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
client: support wpan setting
2018-03-09 18:21:10 +01:00
.setting_name = NM_SETTING_WPAN_SETTING_NAME,
.get_setting_gtype = nm_setting_wpan_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_UNKNOWN] = {
.meta_type = NM_META_SETTING_TYPE_UNKNOWN,
},
};
const NMMetaSettingInfo *
nm_meta_setting_infos_by_name (const char *name)
{
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
gssize idx;
#if NM_MORE_ASSERTS > 10
{
guint i, j;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++) {
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
const NMMetaSettingInfo *setting_info = &nm_meta_setting_infos[i];
nm_assert (setting_info->meta_type == (NMMetaSettingType) i);
nm_assert (setting_info->setting_name);
nm_assert (setting_info->setting_name[0]);
nm_assert (setting_info->get_setting_gtype);
nm_assert (setting_info->setting_priority != NM_SETTING_PRIORITY_INVALID);
if ( i > 0
&& strcmp (nm_meta_setting_infos[i - 1].setting_name, setting_info->setting_name) >= 0) {
g_error ("nm_meta_setting_infos[%u, \"%s\"] is wrongly sorted before nm_meta_setting_infos[%u, \"%s\"]. Rearange NMMetaSettingType enum",
i - 1, nm_meta_setting_infos[i - 1].setting_name,
i, setting_info->setting_name);
}
for (j = 0; j < i; j++) {
const NMMetaSettingInfo *s = &nm_meta_setting_infos[j];
nm_assert (setting_info->get_setting_gtype != s->get_setting_gtype);
}
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
}
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
#endif
G_STATIC_ASSERT_EXPR (G_STRUCT_OFFSET (NMMetaSettingInfo, setting_name) == 0);
idx = nm_utils_array_find_binary_search (nm_meta_setting_infos,
sizeof (NMMetaSettingInfo),
_NM_META_SETTING_TYPE_NUM,
&name,
nm_strcmp_p_with_data,
NULL);
return idx >= 0 ? &nm_meta_setting_infos[idx] : NULL;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
const NMMetaSettingInfo *
nm_meta_setting_infos_by_gtype (GType gtype)
{
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
#if ((NETWORKMANAGER_COMPILATION) & NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_INTERNAL)
nm_auto_unref_gtypeclass GTypeClass *gtypeclass_unref = NULL;
GTypeClass *gtypeclass;
NMSettingClass *klass;
if (!g_type_is_a (gtype, NM_TYPE_SETTING))
goto out_none;
gtypeclass = g_type_class_peek (gtype);
if (!gtypeclass)
gtypeclass = gtypeclass_unref = g_type_class_ref (gtype);
nm_assert (NM_IS_SETTING_CLASS (gtypeclass));
klass = (NMSettingClass *) gtypeclass;
if (!klass->setting_info)
goto out_none;
nm_assert (klass->setting_info->get_setting_gtype);
nm_assert (klass->setting_info->get_setting_gtype () == gtype);
return klass->setting_info;
out_none:
#if NM_MORE_ASSERTS > 10
{
int i;
/* this might hint to a bug, but it would be expected for NM_TYPE_SETTING
* and NM_TYPE_SETTING_IP_CONFIG.
*
* Assert that we didn't lookup for a gtype, which we would expect to find.
* An assertion failure here, hints to a bug in nm_setting_*_class_init().
*/
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++)
nm_assert (nm_meta_setting_infos[i].get_setting_gtype () != gtype);
}
#endif
return NULL;
#else
guint i;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++) {
if (nm_meta_setting_infos[i].get_setting_gtype () == gtype)
return &nm_meta_setting_infos[i];
}
return NULL;
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
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
/*****************************************************************************/
Reference in a new issue Copy permalink