fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-05 03:20:18 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/libnmc-setting/nm-meta-setting-base-impl.c

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

921 lines
35 KiB
C
Raw Permalink 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
*/
libnm: use binary search for nm_meta_setting_infos_by_gtype() for libnmc The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and "libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the gtype. For "libnmc-setting", that class information is not available, so it did a linear search. Instead, do a binary search. Tested: diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c index 3434c858391f..62c366d2ca42 100644 --- a/src/libnm-core-impl/nm-meta-setting-base-impl.c +++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c @@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype) { const NMMetaSettingInfo *setting_info; +#if _NM_META_SETTING_BASE_IMPL_LIBNM + return _infos_by_gtype_binary_search(gtype); +#endif + nm_assert_not_reached(); + #if _NM_META_SETTING_BASE_IMPL_LIBNM setting_info = _infos_by_gtype_from_class(gtype); #else diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c index 85d549eb766c..65fcafd076c9 100644 --- a/src/libnm-core-impl/tests/test-setting.c +++ b/src/libnm-core-impl/tests/test-setting.c @@ -5134,6 +5134,29 @@ main(int argc, char **argv) { nmtst_init(&argc, &argv, TRUE); + { + gs_unref_object NMConnection *con = NULL; + guint8 ctr = 0; + guint i; + + con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL); + + nm_connection_add_setting(con, nm_setting_wired_new()); + + nmtst_connection_normalize(con); + nmtst_assert_connection_verifies_without_normalization(con); + + for (i = 0; i < 10000000; i++) { + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG)); + } + + return !!ctr; + } + g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid); g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority", Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`: 1) previous linear search: 3,182.81 msec 2) bsearch not inlined: 1,611.19 msec 3) bsearch open-coded: 1,214.45 msec 4) bsearch inlined: 1,167.70 msec 5) lookup from class: 1,147.64 msec 1) previous implementation 2) using nm_array_find_bsearch() 3) manually implementing binary search 4) using nm_array_find_bsearch_inline() 5) only available to libnm-core as it uses internal meta data Note that for "libnm-core-impl" the implementation was already fast (5), and it didn't change. It only changed to binary search for "libnmc-setting", which arguably is a less strong use-case.
2022-09-06 11:29:20 +02:00
#define NM_WANT_NM_ARRAY_FIND_BSEARCH_INLINE
build: move "shared/nm-{glib-aux,log-null,log-core}" to "src/libnm-{glib-aux,log-null,log-core}"
2021-02-18 17:37:47 +01:00
#include "libnm-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
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
#if _NM_META_SETTING_BASE_IMPL_LIBNM
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#include "libnm-core-impl/nm-default-libnm-core.h"
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
#endif
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"
bond: add support of queue_id of bond port Introduced `NMSettingBondPort` to hold the new setting class with single property `NM_SETTING_BOND_PORT_QUEUE_ID`. For dbus interface, please use `bond-port` as setting name and `queue-id` as property name. Unit test cases for ifcfg reader and writer included. Signed-off-by: Gris Ge <fge@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1949127 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/952
2021-08-23 22:00:54 +08:00
#include "nm-setting-bond-port.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#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"
HSR: add support to HSR/PRP interface This patch add support to HSR/PRP interface. Please notice that PRP driver is represented as HSR too. They are different drivers but on kernel they are integrated together. HSR/PRP is a network protocol standard for Ethernet that provides seamless failover against failure of any network component. It intends to be transparent to the application. These protocols are useful for applications that request high availability and short switchover time e.g electrical substation or high power inverters. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
2023-10-27 14:01:13 +02:00
#include "nm-setting-hsr.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"
ipvlan: add support to IPVLAN interface This patch add support to IPVLAN interface. IPVLAN is a driver for a virtual network device that can be used in container environment to access the host network. IPVLAN exposes a single MAC address to the external network regardless the number of IPVLAN device created inside the host network. This means that a user can have multiple IPVLAN devices in multiple containers and the corresponding switch reads a single MAC address. IPVLAN driver is useful when the local switch imposes constraints on the total number of MAC addresses that it can manage.
2024-09-06 14:14:24 +02:00
#include "nm-setting-ipvlan.h"
all: add "link" setting Introduce a new "link" setting that holds properties that are related to the kernel link.
2023-02-16 13:31:30 +01:00
#include "nm-setting-link.h"
support loopback interface Support managing the loopback interface through NM as the users want to set the proper mtu for loopback interface when forwarding the packets. Additionally, the IP addresses, DNS, route and routing rules are also allowed to configure for the loopback connection profiles. https://bugzilla.redhat.com/show_bug.cgi?id=2060905
2022-06-12 19:50:09 -04:00
#include "nm-setting-loopback.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"
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"
ovs: add support for "other_config" settings See `man ovs-vswitchd.conf.db` for documentation of "other_config" keys. https://bugzilla.redhat.com/show_bug.cgi?id=2151455
2023-01-11 11:51:46 +01:00
#include "nm-setting-ovs-interface.h"
#include "nm-setting-ovs-other-config.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"
libnm, nmcli: introduce new "prefix-delegation" setting Introduce a new "prefix-delegation" setting. It contains properties related to the configuration of downstream interfaces using IPv6 prefix-delegation. The only property at the moment is "subnet-id", which specifies which prefix to choose when the delegation contains multiple /64 networks.
2025-03-06 22:14:02 +01:00
#include "nm-setting-prefix-delegation.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#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
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
#if _NM_META_SETTING_BASE_IMPL_LIBNM
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#include "nm-setting-private.h"
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
#endif
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
};
libnm: add nm_setting_8021x_scheme_vtable_by_setting_key() helper Add function to lookup the vtable by name. Implement a binary search.
2022-03-23 12:49:32 +01:00
const NMSetting8021xSchemeVtable *
nm_setting_8021x_scheme_vtable_by_setting_key(const char *key)
{
static const NMSetting8021xSchemeType sorted_index[] = {
NM_SETTING_802_1X_SCHEME_TYPE_CA_CERT,
NM_SETTING_802_1X_SCHEME_TYPE_CLIENT_CERT,
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CA_CERT,
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_CLIENT_CERT,
NM_SETTING_802_1X_SCHEME_TYPE_PHASE2_PRIVATE_KEY,
NM_SETTING_802_1X_SCHEME_TYPE_PRIVATE_KEY,
};
int imin, imax;
nm_assert(key);
if (NM_MORE_ASSERT_ONCE(5)) {
const NMSetting8021xSchemeVtable *vtable_prev = NULL;
int i, j;
for (i = 0; i < (int) G_N_ELEMENTS(sorted_index); i++) {
const NMSetting8021xSchemeType t = sorted_index[i];
const NMSetting8021xSchemeVtable *vtable;
nm_assert(_NM_INT_NOT_NEGATIVE(t));
nm_assert(t < G_N_ELEMENTS(nm_setting_8021x_scheme_vtable) - 1);
for (j = 0; j < i; j++)
nm_assert(t != sorted_index[j]);
vtable = &nm_setting_8021x_scheme_vtable[t];
nm_assert(vtable->scheme_type == t);
nm_assert(vtable->setting_key);
if (vtable_prev)
nm_assert(strcmp(vtable_prev->setting_key, vtable->setting_key) < 0);
vtable_prev = vtable;
}
}
imin = 0;
imax = G_N_ELEMENTS(sorted_index) - 1;
while (imin <= imax) {
const NMSetting8021xSchemeVtable *vtable;
const int imid = imin + (imax - imin) / 2;
int cmp;
vtable = &nm_setting_8021x_scheme_vtable[sorted_index[imid]];
cmp = strcmp(vtable->setting_key, key);
if (cmp == 0)
return vtable;
if (cmp < 0)
imin = imid + 1;
else
imax = imid - 1;
}
return NULL;
}
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,
},
bond: add support of queue_id of bond port Introduced `NMSettingBondPort` to hold the new setting class with single property `NM_SETTING_BOND_PORT_QUEUE_ID`. For dbus interface, please use `bond-port` as setting name and `queue-id` as property name. Unit test cases for ifcfg reader and writer included. Signed-off-by: Gris Ge <fge@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1949127 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/952
2021-08-23 22:00:54 +08:00
[NM_META_SETTING_TYPE_BOND_PORT] =
{
.meta_type = NM_META_SETTING_TYPE_BOND_PORT,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_BOND_PORT_SETTING_NAME,
.get_setting_gtype = nm_setting_bond_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_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,
},
HSR: add support to HSR/PRP interface This patch add support to HSR/PRP interface. Please notice that PRP driver is represented as HSR too. They are different drivers but on kernel they are integrated together. HSR/PRP is a network protocol standard for Ethernet that provides seamless failover against failure of any network component. It intends to be transparent to the application. These protocols are useful for applications that request high availability and short switchover time e.g electrical substation or high power inverters. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
2023-10-27 14:01:13 +02:00
[NM_META_SETTING_TYPE_HSR] =
{
.meta_type = NM_META_SETTING_TYPE_HSR,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_HSR_SETTING_NAME,
.get_setting_gtype = nm_setting_hsr_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,
},
ipvlan: add support to IPVLAN interface This patch add support to IPVLAN interface. IPVLAN is a driver for a virtual network device that can be used in container environment to access the host network. IPVLAN exposes a single MAC address to the external network regardless the number of IPVLAN device created inside the host network. This means that a user can have multiple IPVLAN devices in multiple containers and the corresponding switch reads a single MAC address. IPVLAN driver is useful when the local switch imposes constraints on the total number of MAC addresses that it can manage.
2024-09-06 14:14:24 +02:00
[NM_META_SETTING_TYPE_IPVLAN] =
{
.meta_type = NM_META_SETTING_TYPE_IPVLAN,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_IPVLAN_SETTING_NAME,
.get_setting_gtype = nm_setting_ipvlan_get_type,
},
all: add "link" setting Introduce a new "link" setting that holds properties that are related to the kernel link.
2023-02-16 13:31:30 +01:00
[NM_META_SETTING_TYPE_LINK] =
{
.meta_type = NM_META_SETTING_TYPE_LINK,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_LINK_SETTING_NAME,
.get_setting_gtype = nm_setting_link_get_type,
},
support loopback interface Support managing the loopback interface through NM as the users want to set the proper mtu for loopback interface when forwarding the packets. Additionally, the IP addresses, DNS, route and routing rules are also allowed to configure for the loopback connection profiles. https://bugzilla.redhat.com/show_bug.cgi?id=2060905
2022-06-12 19:50:09 -04:00
[NM_META_SETTING_TYPE_LOOPBACK] =
{
.meta_type = NM_META_SETTING_TYPE_LOOPBACK,
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
.setting_name = NM_SETTING_LOOPBACK_SETTING_NAME,
.get_setting_gtype = nm_setting_loopback_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_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,
libnm-core: set ovs-dpdk and ovs-patch as non-base settings Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This means that they can be used as connection type, for example via "nmcli connection add type ovs-dpdk ...". This is wrong, as both settings can only belong to a connection of type "ovs-interface". Decrease their priority and make them non-base settings. The problem was spotted when trying to add a ovs-patch connection via nmcli: # nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port Warning: controller='s' doesn't refer to any existing profile. (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached (process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ?? (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch" Fixes: d0ec5011638e ('cli: assert that valid_parts are set for base types') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
2025-04-03 10:05:47 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
libnm-core: add ovs-dpdk setting
2019-06-11 15:53:05 +02:00
.setting_name = NM_SETTING_OVS_DPDK_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_dpdk_get_type,
},
ovs: add support for "other_config" settings See `man ovs-vswitchd.conf.db` for documentation of "other_config" keys. https://bugzilla.redhat.com/show_bug.cgi?id=2151455
2023-01-11 11:51:46 +01:00
[NM_META_SETTING_TYPE_OVS_OTHER_CONFIG] =
{
.meta_type = NM_META_SETTING_TYPE_OVS_OTHER_CONFIG,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_OVS_OTHER_CONFIG_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_other_config_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-core: set ovs-dpdk and ovs-patch as non-base settings Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This means that they can be used as connection type, for example via "nmcli connection add type ovs-dpdk ...". This is wrong, as both settings can only belong to a connection of type "ovs-interface". Decrease their priority and make them non-base settings. The problem was spotted when trying to add a ovs-patch connection via nmcli: # nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port Warning: controller='s' doesn't refer to any existing profile. (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached (process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ?? (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch" Fixes: d0ec5011638e ('cli: assert that valid_parts are set for base types') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
2025-04-03 10:05:47 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
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,
},
libnm, nmcli: introduce new "prefix-delegation" setting Introduce a new "prefix-delegation" setting. It contains properties related to the configuration of downstream interfaces using IPv6 prefix-delegation. The only property at the moment is "subnet-id", which specifies which prefix to choose when the delegation contains multiple /64 networks.
2025-03-06 22:14:02 +01:00
[NM_META_SETTING_TYPE_PREFIX_DELEGATION] =
{
.meta_type = NM_META_SETTING_TYPE_PREFIX_DELEGATION,
.setting_priority = NM_SETTING_PRIORITY_IP,
.setting_name = NM_SETTING_PREFIX_DELEGATION_SETTING_NAME,
.get_setting_gtype = nm_setting_prefix_delegation_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_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,
},
};
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
const NMMetaSettingType nm_meta_setting_types_by_priority[] = {
/* NM_SETTING_PRIORITY_CONNECTION */
NM_META_SETTING_TYPE_CONNECTION,
/* NM_SETTING_PRIORITY_HW_BASE */
NM_META_SETTING_TYPE_6LOWPAN,
NM_META_SETTING_TYPE_OLPC_MESH,
NM_META_SETTING_TYPE_WIRELESS,
NM_META_SETTING_TYPE_WIRED,
NM_META_SETTING_TYPE_ADSL,
NM_META_SETTING_TYPE_BOND,
NM_META_SETTING_TYPE_BRIDGE,
NM_META_SETTING_TYPE_CDMA,
NM_META_SETTING_TYPE_DUMMY,
NM_META_SETTING_TYPE_GENERIC,
NM_META_SETTING_TYPE_GSM,
HSR: add support to HSR/PRP interface This patch add support to HSR/PRP interface. Please notice that PRP driver is represented as HSR too. They are different drivers but on kernel they are integrated together. HSR/PRP is a network protocol standard for Ethernet that provides seamless failover against failure of any network component. It intends to be transparent to the application. These protocols are useful for applications that request high availability and short switchover time e.g electrical substation or high power inverters. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
2023-10-27 14:01:13 +02:00
NM_META_SETTING_TYPE_HSR,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_INFINIBAND,
NM_META_SETTING_TYPE_IP_TUNNEL,
ipvlan: add support to IPVLAN interface This patch add support to IPVLAN interface. IPVLAN is a driver for a virtual network device that can be used in container environment to access the host network. IPVLAN exposes a single MAC address to the external network regardless the number of IPVLAN device created inside the host network. This means that a user can have multiple IPVLAN devices in multiple containers and the corresponding switch reads a single MAC address. IPVLAN driver is useful when the local switch imposes constraints on the total number of MAC addresses that it can manage.
2024-09-06 14:14:24 +02:00
NM_META_SETTING_TYPE_IPVLAN,
support loopback interface Support managing the loopback interface through NM as the users want to set the proper mtu for loopback interface when forwarding the packets. Additionally, the IP addresses, DNS, route and routing rules are also allowed to configure for the loopback connection profiles. https://bugzilla.redhat.com/show_bug.cgi?id=2060905
2022-06-12 19:50:09 -04:00
NM_META_SETTING_TYPE_LOOPBACK,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_MACSEC,
NM_META_SETTING_TYPE_MACVLAN,
NM_META_SETTING_TYPE_OVS_BRIDGE,
NM_META_SETTING_TYPE_OVS_INTERFACE,
NM_META_SETTING_TYPE_OVS_PORT,
NM_META_SETTING_TYPE_TEAM,
NM_META_SETTING_TYPE_TUN,
NM_META_SETTING_TYPE_VETH,
NM_META_SETTING_TYPE_VLAN,
NM_META_SETTING_TYPE_VPN,
NM_META_SETTING_TYPE_VRF,
NM_META_SETTING_TYPE_VXLAN,
NM_META_SETTING_TYPE_WIFI_P2P,
NM_META_SETTING_TYPE_WIMAX,
NM_META_SETTING_TYPE_WIREGUARD,
NM_META_SETTING_TYPE_WPAN,
/* NM_SETTING_PRIORITY_HW_NON_BASE */
NM_META_SETTING_TYPE_BLUETOOTH,
/* NM_SETTING_PRIORITY_HW_AUX */
NM_META_SETTING_TYPE_WIRELESS_SECURITY,
NM_META_SETTING_TYPE_802_1X,
NM_META_SETTING_TYPE_DCB,
NM_META_SETTING_TYPE_SERIAL,
NM_META_SETTING_TYPE_SRIOV,
/* NM_SETTING_PRIORITY_AUX */
bond: add support of queue_id of bond port Introduced `NMSettingBondPort` to hold the new setting class with single property `NM_SETTING_BOND_PORT_QUEUE_ID`. For dbus interface, please use `bond-port` as setting name and `queue-id` as property name. Unit test cases for ifcfg reader and writer included. Signed-off-by: Gris Ge <fge@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1949127 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/952
2021-08-23 22:00:54 +08:00
NM_META_SETTING_TYPE_BOND_PORT,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_BRIDGE_PORT,
NM_META_SETTING_TYPE_ETHTOOL,
all: add "link" setting Introduce a new "link" setting that holds properties that are related to the kernel link.
2023-02-16 13:31:30 +01:00
NM_META_SETTING_TYPE_LINK,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_MATCH,
libnm-core: set ovs-dpdk and ovs-patch as non-base settings Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This means that they can be used as connection type, for example via "nmcli connection add type ovs-dpdk ...". This is wrong, as both settings can only belong to a connection of type "ovs-interface". Decrease their priority and make them non-base settings. The problem was spotted when trying to add a ovs-patch connection via nmcli: # nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port Warning: controller='s' doesn't refer to any existing profile. (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached (process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ?? (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch" Fixes: d0ec5011638e ('cli: assert that valid_parts are set for base types') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
2025-04-03 10:05:47 +02:00
NM_META_SETTING_TYPE_OVS_DPDK,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_OVS_EXTERNAL_IDS,
ovs: add support for "other_config" settings See `man ovs-vswitchd.conf.db` for documentation of "other_config" keys. https://bugzilla.redhat.com/show_bug.cgi?id=2151455
2023-01-11 11:51:46 +01:00
NM_META_SETTING_TYPE_OVS_OTHER_CONFIG,
libnm-core: set ovs-dpdk and ovs-patch as non-base settings Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This means that they can be used as connection type, for example via "nmcli connection add type ovs-dpdk ...". This is wrong, as both settings can only belong to a connection of type "ovs-interface". Decrease their priority and make them non-base settings. The problem was spotted when trying to add a ovs-patch connection via nmcli: # nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port Warning: controller='s' doesn't refer to any existing profile. (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached (process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ?? (process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch" Fixes: d0ec5011638e ('cli: assert that valid_parts are set for base types') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
2025-04-03 10:05:47 +02:00
NM_META_SETTING_TYPE_OVS_PATCH,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_PPP,
NM_META_SETTING_TYPE_PPPOE,
NM_META_SETTING_TYPE_TEAM_PORT,
/* NM_SETTING_PRIORITY_IP */
NM_META_SETTING_TYPE_HOSTNAME,
NM_META_SETTING_TYPE_IP4_CONFIG,
NM_META_SETTING_TYPE_IP6_CONFIG,
libnm, nmcli: introduce new "prefix-delegation" setting Introduce a new "prefix-delegation" setting. It contains properties related to the configuration of downstream interfaces using IPv6 prefix-delegation. The only property at the moment is "subnet-id", which specifies which prefix to choose when the delegation contains multiple /64 networks.
2025-03-06 22:14:02 +01:00
NM_META_SETTING_TYPE_PREFIX_DELEGATION,
libnm: add nm_meta_setting_types_by_priority array for sorting settings nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name. Add nm_meta_setting_types_by_priority which provides a mapping with a different sort order (first by priority). We need that sometimes.
2021-06-11 15:28:09 +02:00
NM_META_SETTING_TYPE_PROXY,
NM_META_SETTING_TYPE_TC_CONFIG,
/* NM_SETTING_PRIORITY_USER */
NM_META_SETTING_TYPE_USER,
};
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_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);
glib-aux: rename nm_utils_array_find_binary_search() to nm_array_bsearch() The "nm_utils_" prefix is just too verbose. Drop it. Also, Posix has a bsearch function. As this function is similar, rename it. Note that currently the arguments are provided in differnt order from bsearch(). That will be partly addressed next. That is the main reason for the rename. The next commit will swap the arguments, so do a rename first to get a compilation error when backporting a patch that uses the changed API.
2022-09-27 09:08:35 +02:00
idx = nm_array_find_bsearch(nm_meta_setting_infos,
_NM_META_SETTING_TYPE_NUM,
glib-aux: swap arguments for nm_array_find_bsearch() Have "len" before "elem_size". That is consistent with g_qsort_with_data() and bsearch(), and is also what I would expect. Note that the previous commit just renamed the function. If a user of the new, changed API gets backported to an older branch, we will get a compilation error and note that the arguments need to be adjusted.
2022-09-27 09:14:30 +02:00
sizeof(NMMetaSettingInfo),
glib-aux: rename nm_utils_array_find_binary_search() to nm_array_bsearch() The "nm_utils_" prefix is just too verbose. Drop it. Also, Posix has a bsearch function. As this function is similar, rename it. Note that currently the arguments are provided in differnt order from bsearch(). That will be partly addressed next. That is the main reason for the rename. The next commit will swap the arguments, so do a rename first to get a compilation error when backporting a patch that uses the changed API.
2022-09-27 09:08:35 +02:00
&name,
nm_strcmp_p_with_data,
NULL);
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
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
}
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +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
#if _NM_META_SETTING_BASE_IMPL_LIBNM
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
static const NMMetaSettingInfo *
_infos_by_gtype_from_class(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
nm_auto_unref_gtypeclass GTypeClass *gtypeclass_unref = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GTypeClass *gtypeclass;
NMSettingClass *klass;
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
if (!g_type_is_a(gtype, NM_TYPE_SETTING))
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
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
gtypeclass = g_type_class_peek(gtype);
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
if (G_UNLIKELY(!gtypeclass))
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
gtypeclass = gtypeclass_unref = g_type_class_ref(gtype);
nm_assert(NM_IS_SETTING_CLASS(gtypeclass));
klass = (NMSettingClass *) gtypeclass;
if (!klass->setting_info)
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
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
nm_assert(klass->setting_info->get_setting_gtype);
nm_assert(klass->setting_info->get_setting_gtype() == gtype);
return klass->setting_info;
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
}
#endif
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
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
static const NMMetaSettingInfo *
_infos_by_gtype_search(GType gtype)
{
int i;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
for (i = 0; i < (int) _NM_META_SETTING_TYPE_NUM; i++) {
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
if (nm_meta_setting_infos[i].get_setting_gtype() == gtype)
return &nm_meta_setting_infos[i];
}
return NULL;
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
}
libnm: use binary search for nm_meta_setting_infos_by_gtype() for libnmc The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and "libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the gtype. For "libnmc-setting", that class information is not available, so it did a linear search. Instead, do a binary search. Tested: diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c index 3434c858391f..62c366d2ca42 100644 --- a/src/libnm-core-impl/nm-meta-setting-base-impl.c +++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c @@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype) { const NMMetaSettingInfo *setting_info; +#if _NM_META_SETTING_BASE_IMPL_LIBNM + return _infos_by_gtype_binary_search(gtype); +#endif + nm_assert_not_reached(); + #if _NM_META_SETTING_BASE_IMPL_LIBNM setting_info = _infos_by_gtype_from_class(gtype); #else diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c index 85d549eb766c..65fcafd076c9 100644 --- a/src/libnm-core-impl/tests/test-setting.c +++ b/src/libnm-core-impl/tests/test-setting.c @@ -5134,6 +5134,29 @@ main(int argc, char **argv) { nmtst_init(&argc, &argv, TRUE); + { + gs_unref_object NMConnection *con = NULL; + guint8 ctr = 0; + guint i; + + con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL); + + nm_connection_add_setting(con, nm_setting_wired_new()); + + nmtst_connection_normalize(con); + nmtst_assert_connection_verifies_without_normalization(con); + + for (i = 0; i < 10000000; i++) { + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG)); + } + + return !!ctr; + } + g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid); g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority", Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`: 1) previous linear search: 3,182.81 msec 2) bsearch not inlined: 1,611.19 msec 3) bsearch open-coded: 1,214.45 msec 4) bsearch inlined: 1,167.70 msec 5) lookup from class: 1,147.64 msec 1) previous implementation 2) using nm_array_find_bsearch() 3) manually implementing binary search 4) using nm_array_find_bsearch_inline() 5) only available to libnm-core as it uses internal meta data Note that for "libnm-core-impl" the implementation was already fast (5), and it didn't change. It only changed to binary search for "libnmc-setting", which arguably is a less strong use-case.
2022-09-06 11:29:20 +02:00
typedef struct {
GType gtype;
const NMMetaSettingInfo *setting_info;
} LookupData;
_nm_always_inline static inline int
_lookup_data_cmp(gconstpointer ptr_a, gconstpointer ptr_b, gpointer user_data)
{
const GType *const a = ptr_a;
const GType *const b = ptr_b;
nm_assert(a);
nm_assert(b);
nm_assert(a != b);
NM_CMP_DIRECT(*a, *b);
return 0;
}
static const NMMetaSettingInfo *
_infos_by_gtype_binary_search(GType gtype)
{
static LookupData static_array[_NM_META_SETTING_TYPE_NUM];
static const LookupData *static_ptr = NULL;
const LookupData *ptr;
gssize idx;
again:
ptr = g_atomic_pointer_get(&static_ptr);
if (G_UNLIKELY(!ptr)) {
static gsize g_lock = 0;
int i;
if (!g_once_init_enter(&g_lock))
goto again;
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++) {
const NMMetaSettingInfo *m = &nm_meta_setting_infos[i];
format: run nm-code-format Reformat with: clang-format version 19.1.0 (Fedora 19.1.0-1.fc41) https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2046
2024-10-04 10:45:56 +02:00
static_array[i] = (LookupData) {
libnm: use binary search for nm_meta_setting_infos_by_gtype() for libnmc The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and "libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the gtype. For "libnmc-setting", that class information is not available, so it did a linear search. Instead, do a binary search. Tested: diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c index 3434c858391f..62c366d2ca42 100644 --- a/src/libnm-core-impl/nm-meta-setting-base-impl.c +++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c @@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype) { const NMMetaSettingInfo *setting_info; +#if _NM_META_SETTING_BASE_IMPL_LIBNM + return _infos_by_gtype_binary_search(gtype); +#endif + nm_assert_not_reached(); + #if _NM_META_SETTING_BASE_IMPL_LIBNM setting_info = _infos_by_gtype_from_class(gtype); #else diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c index 85d549eb766c..65fcafd076c9 100644 --- a/src/libnm-core-impl/tests/test-setting.c +++ b/src/libnm-core-impl/tests/test-setting.c @@ -5134,6 +5134,29 @@ main(int argc, char **argv) { nmtst_init(&argc, &argv, TRUE); + { + gs_unref_object NMConnection *con = NULL; + guint8 ctr = 0; + guint i; + + con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL); + + nm_connection_add_setting(con, nm_setting_wired_new()); + + nmtst_connection_normalize(con); + nmtst_assert_connection_verifies_without_normalization(con); + + for (i = 0; i < 10000000; i++) { + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG)); + } + + return !!ctr; + } + g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid); g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority", Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`: 1) previous linear search: 3,182.81 msec 2) bsearch not inlined: 1,611.19 msec 3) bsearch open-coded: 1,214.45 msec 4) bsearch inlined: 1,167.70 msec 5) lookup from class: 1,147.64 msec 1) previous implementation 2) using nm_array_find_bsearch() 3) manually implementing binary search 4) using nm_array_find_bsearch_inline() 5) only available to libnm-core as it uses internal meta data Note that for "libnm-core-impl" the implementation was already fast (5), and it didn't change. It only changed to binary search for "libnmc-setting", which arguably is a less strong use-case.
2022-09-06 11:29:20 +02:00
.gtype = m->get_setting_gtype(),
.setting_info = m,
};
}
g_qsort_with_data(static_array,
_NM_META_SETTING_TYPE_NUM,
sizeof(static_array[0]),
_lookup_data_cmp,
NULL);
ptr = static_array;
g_atomic_pointer_set(&static_ptr, ptr);
g_once_init_leave(&g_lock, 1);
}
idx = nm_array_find_bsearch_inline(ptr,
_NM_META_SETTING_TYPE_NUM,
sizeof(ptr[0]),
&gtype,
_lookup_data_cmp,
NULL);
if (idx < 0)
return NULL;
return ptr[idx].setting_info;
}
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
const NMMetaSettingInfo *
nm_meta_setting_infos_by_gtype(GType gtype)
{
const NMMetaSettingInfo *setting_info;
#if _NM_META_SETTING_BASE_IMPL_LIBNM
setting_info = _infos_by_gtype_from_class(gtype);
#else
libnm: use binary search for nm_meta_setting_infos_by_gtype() for libnmc The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and "libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the gtype. For "libnmc-setting", that class information is not available, so it did a linear search. Instead, do a binary search. Tested: diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c index 3434c858391f..62c366d2ca42 100644 --- a/src/libnm-core-impl/nm-meta-setting-base-impl.c +++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c @@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype) { const NMMetaSettingInfo *setting_info; +#if _NM_META_SETTING_BASE_IMPL_LIBNM + return _infos_by_gtype_binary_search(gtype); +#endif + nm_assert_not_reached(); + #if _NM_META_SETTING_BASE_IMPL_LIBNM setting_info = _infos_by_gtype_from_class(gtype); #else diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c index 85d549eb766c..65fcafd076c9 100644 --- a/src/libnm-core-impl/tests/test-setting.c +++ b/src/libnm-core-impl/tests/test-setting.c @@ -5134,6 +5134,29 @@ main(int argc, char **argv) { nmtst_init(&argc, &argv, TRUE); + { + gs_unref_object NMConnection *con = NULL; + guint8 ctr = 0; + guint i; + + con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL); + + nm_connection_add_setting(con, nm_setting_wired_new()); + + nmtst_connection_normalize(con); + nmtst_assert_connection_verifies_without_normalization(con); + + for (i = 0; i < 10000000; i++) { + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG)); + } + + return !!ctr; + } + g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid); g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority", Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`: 1) previous linear search: 3,182.81 msec 2) bsearch not inlined: 1,611.19 msec 3) bsearch open-coded: 1,214.45 msec 4) bsearch inlined: 1,167.70 msec 5) lookup from class: 1,147.64 msec 1) previous implementation 2) using nm_array_find_bsearch() 3) manually implementing binary search 4) using nm_array_find_bsearch_inline() 5) only available to libnm-core as it uses internal meta data Note that for "libnm-core-impl" the implementation was already fast (5), and it didn't change. It only changed to binary search for "libnmc-setting", which arguably is a less strong use-case.
2022-09-06 11:29:20 +02:00
setting_info = _infos_by_gtype_binary_search(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
#endif
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
libnm: use binary search for nm_meta_setting_infos_by_gtype() for libnmc The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and "libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the gtype. For "libnmc-setting", that class information is not available, so it did a linear search. Instead, do a binary search. Tested: diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c index 3434c858391f..62c366d2ca42 100644 --- a/src/libnm-core-impl/nm-meta-setting-base-impl.c +++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c @@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype) { const NMMetaSettingInfo *setting_info; +#if _NM_META_SETTING_BASE_IMPL_LIBNM + return _infos_by_gtype_binary_search(gtype); +#endif + nm_assert_not_reached(); + #if _NM_META_SETTING_BASE_IMPL_LIBNM setting_info = _infos_by_gtype_from_class(gtype); #else diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c index 85d549eb766c..65fcafd076c9 100644 --- a/src/libnm-core-impl/tests/test-setting.c +++ b/src/libnm-core-impl/tests/test-setting.c @@ -5134,6 +5134,29 @@ main(int argc, char **argv) { nmtst_init(&argc, &argv, TRUE); + { + gs_unref_object NMConnection *con = NULL; + guint8 ctr = 0; + guint i; + + con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL); + + nm_connection_add_setting(con, nm_setting_wired_new()); + + nmtst_connection_normalize(con); + nmtst_assert_connection_verifies_without_normalization(con); + + for (i = 0; i < 10000000; i++) { + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD)); + ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG)); + } + + return !!ctr; + } + g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid); g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority", Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`: 1) previous linear search: 3,182.81 msec 2) bsearch not inlined: 1,611.19 msec 3) bsearch open-coded: 1,214.45 msec 4) bsearch inlined: 1,167.70 msec 5) lookup from class: 1,147.64 msec 1) previous implementation 2) using nm_array_find_bsearch() 3) manually implementing binary search 4) using nm_array_find_bsearch_inline() 5) only available to libnm-core as it uses internal meta data Note that for "libnm-core-impl" the implementation was already fast (5), and it didn't change. It only changed to binary search for "libnmc-setting", which arguably is a less strong use-case.
2022-09-06 11:29:20 +02:00
if (NM_MORE_ASSERTS > 20) {
nm_assert(setting_info == _infos_by_gtype_search(gtype));
nm_assert(setting_info == _infos_by_gtype_binary_search(gtype));
}
libnm: cleanup implementations for nm_meta_setting_infos_by_gtype() The file "nm-meta-setting-base-impl.c" is present twice in our source tree and compiled twice. Once with internal headers of libnm-core and once with only public headers. Consequently, there are two implementations for nm_meta_setting_infos_by_gtype(), one that can benefit from internal access to the data structure, and the one for libnmc, which cannot. Refactor the implementations, in the hope to have it clearer.
2022-09-06 11:29:20 +02:00
return setting_info;
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