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

514 lines
21 KiB
C
Raw Normal View History

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
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
/*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301 USA.
*
client: support wpan setting
2018-03-09 18:21:10 +01:00
* Copyright 2017 - 2018 Red Hat, Inc.
all: add new "shared/nm-setting-metadata.h" file "shared/nm-setting-metadata.h" will contain data structures to handle NM setting properties in a generic way. For now, this is internal API, but shared between libnm-core (which extends to libnm, NetworkManager, device-plugins, settings-plugins), and nmcli. Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
2017-02-17 17:10:44 +01:00
*/
#include "nm-default.h"
cli: split nm-meta-setting-desc out of settings This part contains static functions and variables to describe settings. It is distinct from the mechanism to use them, or access them. Split it out. It still uses clients/cli/common.h and clients/cli/utils.h which shall be fixed next.
2017-03-28 11:38:00 +02:00
#include "nm-meta-setting.h"
all: add new "shared/nm-setting-metadata.h" file "shared/nm-setting-metadata.h" will contain data structures to handle NM setting properties in a generic way. For now, this is internal API, but shared between libnm-core (which extends to libnm, NetworkManager, device-plugins, settings-plugins), and nmcli. Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
2017-02-17 17:10:44 +01:00
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
#include "nm-setting-6lowpan.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-8021x.h"
#include "nm-setting-adsl.h"
#include "nm-setting-bluetooth.h"
#include "nm-setting-bond.h"
#include "nm-setting-bridge.h"
#include "nm-setting-bridge-port.h"
#include "nm-setting-cdma.h"
#include "nm-setting-connection.h"
#include "nm-setting-dcb.h"
#include "nm-setting-dummy.h"
libnm, cli, ifcfg-rh: add NMSettingEthtool setting Note that in NetworkManager API (D-Bus, libnm, and nmcli), the features are called "feature-xyz". The "feature-" prefix is used, because NMSettingEthtool possibly will gain support for options that are not only -K|--offload|--features, for example -C|--coalesce. The "xzy" suffix is either how ethtool utility calls the feature ("tso", "rx"). Or, if ethtool utility specifies no alias for that feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation"). If possible, we prefer ethtool utility's naming. Also note, how the features "feature-sg", "feature-tso", and "feature-tx" actually refer to multiple underlying kernel features at once. This too follows what ethtool utility does. The functionality is not yet implemented server-side.
2018-07-16 23:37:55 +02:00
#include "nm-setting-ethtool.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-generic.h"
#include "nm-setting-gsm.h"
#include "nm-setting-infiniband.h"
#include "nm-setting-ip4-config.h"
#include "nm-setting-ip6-config.h"
#include "nm-setting-ip-config.h"
#include "nm-setting-ip-tunnel.h"
#include "nm-setting-macsec.h"
#include "nm-setting-macvlan.h"
#include "nm-setting-olpc-mesh.h"
clients: add support for ovs-bridge setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-bridge.h"
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-interface.h"
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-patch.h"
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
#include "nm-setting-ovs-port.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-ppp.h"
#include "nm-setting-pppoe.h"
#include "nm-setting-proxy.h"
#include "nm-setting-serial.h"
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
#include "nm-setting-tc-config.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
#include "nm-setting-team.h"
#include "nm-setting-team-port.h"
#include "nm-setting-tun.h"
#include "nm-setting-user.h"
#include "nm-setting-vlan.h"
#include "nm-setting-vpn.h"
#include "nm-setting-vxlan.h"
#include "nm-setting-wimax.h"
#include "nm-setting-wired.h"
#include "nm-setting-wireless.h"
#include "nm-setting-wireless-security.h"
client: support wpan setting
2018-03-09 18:21:10 +01:00
#include "nm-setting-wpan.h"
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
shared: move NMSetting8021xSchemeVtable to "shared/nm-setting-metadata.h"
2017-02-17 17:16:38 +01:00
/*****************************************************************************/
const NMSetting8021xSchemeVtable nm_setting_8021x_scheme_vtable[] = {
[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,
.file_suffix = "ca-cert",
},
[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,
.file_suffix = "inner-ca-cert",
},
[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,
.file_suffix = "client-cert",
},
[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,
.file_suffix = "inner-client-cert",
},
[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,
.file_suffix = "private-key",
},
[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,
.file_suffix = "inner-private-key",
},
[NM_SETTING_802_1X_SCHEME_TYPE_UNKNOWN] = { NULL },
};
/*****************************************************************************/
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
const NMMetaSettingInfo nm_meta_setting_infos[] = {
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
[NM_META_SETTING_TYPE_6LOWPAN] = {
.meta_type = NM_META_SETTING_TYPE_6LOWPAN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
client: support 6lowpan setting
2018-05-22 17:11:30 +02:00
.setting_name = NM_SETTING_6LOWPAN_SETTING_NAME,
.get_setting_gtype = nm_setting_6lowpan_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_802_1X] = {
.meta_type = NM_META_SETTING_TYPE_802_1X,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_802_1X_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_802_1x_get_type,
},
[NM_META_SETTING_TYPE_ADSL] = {
.meta_type = NM_META_SETTING_TYPE_ADSL,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_ADSL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_adsl_get_type,
},
[NM_META_SETTING_TYPE_BLUETOOTH] = {
.meta_type = NM_META_SETTING_TYPE_BLUETOOTH,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_NON_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BLUETOOTH_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bluetooth_get_type,
},
[NM_META_SETTING_TYPE_BOND] = {
.meta_type = NM_META_SETTING_TYPE_BOND,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BOND_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bond_get_type,
},
[NM_META_SETTING_TYPE_BRIDGE] = {
.meta_type = NM_META_SETTING_TYPE_BRIDGE,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BRIDGE_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bridge_get_type,
},
[NM_META_SETTING_TYPE_BRIDGE_PORT] = {
.meta_type = NM_META_SETTING_TYPE_BRIDGE_PORT,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_BRIDGE_PORT_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_bridge_port_get_type,
},
[NM_META_SETTING_TYPE_CDMA] = {
.meta_type = NM_META_SETTING_TYPE_CDMA,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_CDMA_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_cdma_get_type,
},
[NM_META_SETTING_TYPE_CONNECTION] = {
.meta_type = NM_META_SETTING_TYPE_CONNECTION,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_CONNECTION,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_CONNECTION_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_connection_get_type,
},
[NM_META_SETTING_TYPE_DCB] = {
.meta_type = NM_META_SETTING_TYPE_DCB,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_DCB_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_dcb_get_type,
},
cli: add property-info for the rest
2017-03-26 14:30:17 +02:00
[NM_META_SETTING_TYPE_DUMMY] = {
.meta_type = NM_META_SETTING_TYPE_DUMMY,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_DUMMY_SETTING_NAME,
cli: add property-info for the rest
2017-03-26 14:30:17 +02:00
.get_setting_gtype = nm_setting_dummy_get_type,
},
libnm, cli, ifcfg-rh: add NMSettingEthtool setting Note that in NetworkManager API (D-Bus, libnm, and nmcli), the features are called "feature-xyz". The "feature-" prefix is used, because NMSettingEthtool possibly will gain support for options that are not only -K|--offload|--features, for example -C|--coalesce. The "xzy" suffix is either how ethtool utility calls the feature ("tso", "rx"). Or, if ethtool utility specifies no alias for that feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation"). If possible, we prefer ethtool utility's naming. Also note, how the features "feature-sg", "feature-tso", and "feature-tx" actually refer to multiple underlying kernel features at once. This too follows what ethtool utility does. The functionality is not yet implemented server-side.
2018-07-16 23:37:55 +02:00
[NM_META_SETTING_TYPE_ETHTOOL] = {
.meta_type = NM_META_SETTING_TYPE_ETHTOOL,
.setting_priority = NM_SETTING_PRIORITY_AUX,
.setting_name = NM_SETTING_ETHTOOL_SETTING_NAME,
.get_setting_gtype = nm_setting_ethtool_get_type,
},
cli: add meta data for NMSettingGeneric
2017-04-10 21:40:19 +02:00
[NM_META_SETTING_TYPE_GENERIC] = {
.meta_type = NM_META_SETTING_TYPE_GENERIC,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_GENERIC_SETTING_NAME,
cli: add meta data for NMSettingGeneric
2017-04-10 21:40:19 +02:00
.get_setting_gtype = nm_setting_generic_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_GSM] = {
.meta_type = NM_META_SETTING_TYPE_GSM,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_GSM_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_gsm_get_type,
},
[NM_META_SETTING_TYPE_INFINIBAND] = {
.meta_type = NM_META_SETTING_TYPE_INFINIBAND,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_INFINIBAND_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_infiniband_get_type,
},
[NM_META_SETTING_TYPE_IP4_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_IP4_CONFIG,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP4_CONFIG_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip4_config_get_type,
},
[NM_META_SETTING_TYPE_IP6_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_IP6_CONFIG,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP6_CONFIG_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip6_config_get_type,
},
[NM_META_SETTING_TYPE_IP_TUNNEL] = {
.meta_type = NM_META_SETTING_TYPE_IP_TUNNEL,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_IP_TUNNEL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ip_tunnel_get_type,
},
[NM_META_SETTING_TYPE_MACSEC] = {
.meta_type = NM_META_SETTING_TYPE_MACSEC,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_MACSEC_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_macsec_get_type,
},
[NM_META_SETTING_TYPE_MACVLAN] = {
.meta_type = NM_META_SETTING_TYPE_MACVLAN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_MACVLAN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_macvlan_get_type,
},
[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,
},
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_INTERFACE] = {
.meta_type = NM_META_SETTING_TYPE_OVS_INTERFACE,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-interface setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_INTERFACE_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_interface_get_type,
},
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_PATCH] = {
.meta_type = NM_META_SETTING_TYPE_OVS_PATCH,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-patch setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_PATCH_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_patch_get_type,
},
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
[NM_META_SETTING_TYPE_OVS_PORT] = {
.meta_type = NM_META_SETTING_TYPE_OVS_PORT,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
clients: add support for ovs-port setting
2017-08-01 20:28:05 +02:00
.setting_name = NM_SETTING_OVS_PORT_SETTING_NAME,
.get_setting_gtype = nm_setting_ovs_port_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_PPPOE] = {
.meta_type = NM_META_SETTING_TYPE_PPPOE,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PPPOE_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_pppoe_get_type,
},
[NM_META_SETTING_TYPE_PPP] = {
.meta_type = NM_META_SETTING_TYPE_PPP,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PPP_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_ppp_get_type,
},
[NM_META_SETTING_TYPE_PROXY] = {
.meta_type = NM_META_SETTING_TYPE_PROXY,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_IP,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_PROXY_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_proxy_get_type,
},
[NM_META_SETTING_TYPE_SERIAL] = {
.meta_type = NM_META_SETTING_TYPE_SERIAL,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_SERIAL_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_serial_get_type,
},
cli: add support for configuring SR-IOV
2018-05-24 17:48:37 +02:00
[NM_META_SETTING_TYPE_SRIOV] = {
.meta_type = NM_META_SETTING_TYPE_SRIOV,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: add support for configuring SR-IOV
2018-05-24 17:48:37 +02:00
.setting_name = NM_SETTING_SRIOV_SETTING_NAME,
.get_setting_gtype = nm_setting_sriov_get_type,
},
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
[NM_META_SETTING_TYPE_TC_CONFIG] = {
.meta_type = NM_META_SETTING_TYPE_TC_CONFIG,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_IP,
clients: add tc qdisc support What works: nmcli c add con-name dum0 ifname dum0 type dummy \ tc.qdiscs 'ingress, root pfifo_fast' nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast' nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'
2017-11-16 19:19:37 +01:00
.setting_name = NM_SETTING_TC_CONFIG_SETTING_NAME,
.get_setting_gtype = nm_setting_tc_config_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_TEAM] = {
.meta_type = NM_META_SETTING_TYPE_TEAM,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TEAM_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_team_get_type,
},
[NM_META_SETTING_TYPE_TEAM_PORT] = {
.meta_type = NM_META_SETTING_TYPE_TEAM_PORT,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TEAM_PORT_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_team_port_get_type,
},
[NM_META_SETTING_TYPE_TUN] = {
.meta_type = NM_META_SETTING_TYPE_TUN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_TUN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_tun_get_type,
},
[NM_META_SETTING_TYPE_USER] = {
.meta_type = NM_META_SETTING_TYPE_USER,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_USER,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_USER_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_user_get_type,
},
[NM_META_SETTING_TYPE_VLAN] = {
.meta_type = NM_META_SETTING_TYPE_VLAN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_VLAN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_vlan_get_type,
},
[NM_META_SETTING_TYPE_VPN] = {
.meta_type = NM_META_SETTING_TYPE_VPN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_VPN_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_vpn_get_type,
},
[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,
},
[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,
},
[NM_META_SETTING_TYPE_WIRELESS] = {
.meta_type = NM_META_SETTING_TYPE_WIRELESS,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIRELESS_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wireless_get_type,
},
[NM_META_SETTING_TYPE_WIRELESS_SECURITY] = {
.meta_type = NM_META_SETTING_TYPE_WIRELESS_SECURITY,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_AUX,
cli: don't mark field names for translation Before refactoring nmcli recently, field names were marked for translation. Note that for the property names, marking them had no effect as only plain strings can be marked with N_(). Note how --fields are also an input argument. The input should be independent of the locale and not translated. Likewise, when printing the header names, they should not be translated to match the --fields option. $ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25 GENERAL.GERÄT: enp0s25 Drop the translation marks.
2017-04-20 10:22:52 +02:00
.setting_name = NM_SETTING_WIRELESS_SECURITY_SETTING_NAME,
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
.get_setting_gtype = nm_setting_wireless_security_get_type,
},
client: support wpan setting
2018-03-09 18:21:10 +01:00
[NM_META_SETTING_TYPE_WPAN] = {
.meta_type = NM_META_SETTING_TYPE_WPAN,
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
.setting_priority = NM_SETTING_PRIORITY_HW_BASE,
client: support wpan setting
2018-03-09 18:21:10 +01:00
.setting_name = NM_SETTING_WPAN_SETTING_NAME,
.get_setting_gtype = nm_setting_wpan_get_type,
},
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
[NM_META_SETTING_TYPE_UNKNOWN] = {
.meta_type = NM_META_SETTING_TYPE_UNKNOWN,
},
};
const NMMetaSettingInfo *
nm_meta_setting_infos_by_name (const char *name)
{
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
gssize idx;
#if NM_MORE_ASSERTS > 10
{
guint i, j;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++) {
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
const NMMetaSettingInfo *setting_info = &nm_meta_setting_infos[i];
nm_assert (setting_info->meta_type == (NMMetaSettingType) i);
nm_assert (setting_info->setting_name);
nm_assert (setting_info->setting_name[0]);
nm_assert (setting_info->get_setting_gtype);
nm_assert (setting_info->setting_priority != NM_SETTING_PRIORITY_INVALID);
if ( i > 0
&& strcmp (nm_meta_setting_infos[i - 1].setting_name, setting_info->setting_name) >= 0) {
g_error ("nm_meta_setting_infos[%u, \"%s\"] is wrongly sorted before nm_meta_setting_infos[%u, \"%s\"]. Rearange NMMetaSettingType enum",
i - 1, nm_meta_setting_infos[i - 1].setting_name,
i, setting_info->setting_name);
}
for (j = 0; j < i; j++) {
const NMMetaSettingInfo *s = &nm_meta_setting_infos[j];
nm_assert (setting_info->get_setting_gtype != s->get_setting_gtype);
}
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
}
shared: use binary search in nm_meta_setting_infos_by_name() nm_meta_setting_infos_by_name() did a naive search by name by iterating over all 42 setting types. Reorder nm_meta_setting_infos array, and use binary search instead.
2018-07-28 12:56:57 +02:00
#endif
G_STATIC_ASSERT_EXPR (G_STRUCT_OFFSET (NMMetaSettingInfo, setting_name) == 0);
idx = nm_utils_array_find_binary_search (nm_meta_setting_infos,
sizeof (NMMetaSettingInfo),
_NM_META_SETTING_TYPE_NUM,
&name,
nm_strcmp_p_with_data,
NULL);
return idx >= 0 ? &nm_meta_setting_infos[idx] : NULL;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
const NMMetaSettingInfo *
nm_meta_setting_infos_by_gtype (GType gtype)
{
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
#if ((NETWORKMANAGER_COMPILATION) & NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_INTERNAL)
nm_auto_unref_gtypeclass GTypeClass *gtypeclass_unref = NULL;
GTypeClass *gtypeclass;
NMSettingClass *klass;
if (!g_type_is_a (gtype, NM_TYPE_SETTING))
goto out_none;
gtypeclass = g_type_class_peek (gtype);
if (!gtypeclass)
gtypeclass = gtypeclass_unref = g_type_class_ref (gtype);
nm_assert (NM_IS_SETTING_CLASS (gtypeclass));
klass = (NMSettingClass *) gtypeclass;
if (!klass->setting_info)
goto out_none;
nm_assert (klass->setting_info->get_setting_gtype);
nm_assert (klass->setting_info->get_setting_gtype () == gtype);
return klass->setting_info;
out_none:
#if NM_MORE_ASSERTS > 10
{
int i;
/* this might hint to a bug, but it would be expected for NM_TYPE_SETTING
* and NM_TYPE_SETTING_IP_CONFIG.
*
* Assert that we didn't lookup for a gtype, which we would expect to find.
* An assertion failure here, hints to a bug in nm_setting_*_class_init().
*/
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++)
nm_assert (nm_meta_setting_infos[i].get_setting_gtype () != gtype);
}
#endif
return NULL;
#else
guint i;
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
for (i = 0; i < _NM_META_SETTING_TYPE_NUM; i++) {
if (nm_meta_setting_infos[i].get_setting_gtype () == gtype)
return &nm_meta_setting_infos[i];
}
return NULL;
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
#endif
meta: add table @nm_meta_setting_infos of all settings types
2017-03-24 15:55:19 +01:00
}
/*****************************************************************************/
Reference in a new issue Copy permalink