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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

642 lines
26 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
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
*/
all: add "libnm/nm-default-client.h" as replacement for "nm-default.h"
2021-02-04 11:05:19 +01:00
#include "nm-glib-aux/nm-default-glib-i18n-lib.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
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
#include "nm-meta-setting-base.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"
all: add hostname setting Add a new setting that contains properties related to how NM should get the hostname from the connection.
2020-10-31 10:50:56 +01:00
#include "nm-setting-hostname.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#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"
libnm: add NMSettingOvsExternalIDs
2020-11-02 17:29:26 +01:00
#include "nm-setting-ovs-external-ids.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"
veth: add support to configure veth interfaces NetworkManager is now able to configure veth interfaces throught the NMSettingVeth. Veth interfaces only have "peer" property. In order to support Veth interfaces in NetworkManager the design need to pass the following requirements: * Veth setting only has "peer" attribute. * Ethernet profiles must be applicable to Veth interfaces. * When creating a veth interface, the peer will be managed by NetworkManager but will not have a profile. * Veth connection can reapply only if the peer has not been modified. * In order to modify the veth peer, NetworkManager must deactivate the connection and create a new one with peer modified. In general, it should support the basis of veth interfaces but without breaking any existing feature or use case. The users that are using veth interfaces as ethernet should not notice anything changed unless they specified the veth peer setting. Creating a Veth interface in NetworkManager is useful even without the support for namespaces for some use cases, e.g "connecting one side of the veth to an OVS bridge and the other side to a Linux bridge" this is done when using OVN kubernetes [1][2]. In addition, it would provide persistent configuration and rollback support for Veth interfaces. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139 Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2020-11-12 21:58:13 +01:00
#include "nm-setting-veth.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#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__}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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", ),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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", ),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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", ),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_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", ),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_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, ),
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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_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,
},
all: add hostname setting Add a new setting that contains properties related to how NM should get the hostname from the connection.
2020-10-31 10:50:56 +01:00
[NM_META_SETTING_TYPE_HOSTNAME] =
{
.meta_type = NM_META_SETTING_TYPE_HOSTNAME,
.setting_priority = NM_SETTING_PRIORITY_IP,
.setting_name = NM_SETTING_HOSTNAME_SETTING_NAME,
.get_setting_gtype = nm_setting_hostname_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_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,
},
libnm: add NMSettingOvsExternalIDs
2020-11-02 17:29:26 +01:00
[NM_META_SETTING_TYPE_OVS_EXTERNAL_IDS] =
{
.meta_type = NM_META_SETTING_TYPE_OVS_EXTERNAL_IDS,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_OVS_EXTERNAL_IDS_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_external_ids_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,
},
veth: add support to configure veth interfaces NetworkManager is now able to configure veth interfaces throught the NMSettingVeth. Veth interfaces only have "peer" property. In order to support Veth interfaces in NetworkManager the design need to pass the following requirements: * Veth setting only has "peer" attribute. * Ethernet profiles must be applicable to Veth interfaces. * When creating a veth interface, the peer will be managed by NetworkManager but will not have a profile. * Veth connection can reapply only if the peer has not been modified. * In order to modify the veth peer, NetworkManager must deactivate the connection and create a new one with peer modified. In general, it should support the basis of veth interfaces but without breaking any existing feature or use case. The users that are using veth interfaces as ethernet should not notice anything changed unless they specified the veth peer setting. Creating a Veth interface in NetworkManager is useful even without the support for namespaces for some use cases, e.g "connecting one side of the veth to an OVS bridge and the other side to a Linux bridge" this is done when using OVN kubernetes [1][2]. In addition, it would provide persistent configuration and rollback support for Veth interfaces. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139 Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2020-11-12 21:58:13 +01:00
[NM_META_SETTING_TYPE_VETH] =
{
.meta_type = NM_META_SETTING_TYPE_VETH,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_VETH_SETTING_NAME,
.get_setting_gtype = nm_setting_veth_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_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,
},
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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;
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
if (NM_MORE_ASSERTS > 10) {
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
guint i, j;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
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];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02: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
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
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)
{
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
#if _NM_META_SETTING_BASE_IMPL_LIBNM
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
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:
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
if (NM_MORE_ASSERTS > 10) {
int i;
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
/* this might hint to a bug, but it would be expected for NM_TYPE_SETTING
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
* 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().
*/
all: move shared/nm-meta-setting.[hc] to libnm-core and clients "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
2021-02-07 10:53:44 +01:00
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++)
nm_assert(nm_meta_setting_infos[i].get_setting_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
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
}
/*****************************************************************************/
shared/libnm: move NMSettingPriority helpers to "shared/nm-meta-setting.h"
2020-11-16 09:50:27 +01:00
NMSettingPriority
nm_meta_setting_info_get_base_type_priority(const NMMetaSettingInfo *setting_info, GType gtype)
{
/* Historical oddity: PPPoE is a base-type even though it's not
* priority 1. It needs to be sorted *after* lower-level stuff like
* Wi-Fi security or 802.1x for secrets, but it's still allowed as a
* base type.
*/
if (setting_info) {
if (NM_IN_SET(setting_info->setting_priority,
NM_SETTING_PRIORITY_HW_BASE,
NM_SETTING_PRIORITY_HW_NON_BASE)
|| gtype == NM_TYPE_SETTING_PPPOE)
return setting_info->setting_priority;
}
return NM_SETTING_PRIORITY_INVALID;
}
NMSettingPriority
_nm_setting_type_get_base_type_priority(GType type)
{
return nm_meta_setting_info_get_base_type_priority(nm_meta_setting_infos_by_gtype(type), type);
}
/*****************************************************************************/
Reference in a new issue Copy permalink