fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-20 08:10:06 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/libnm-core-impl/nm-setting-private.h

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

718 lines
41 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2011 Red Hat, Inc.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
all: fix up multiple-include-guard defines Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include guard, which meant that nm-test-utils.h could not tell which of them was being included (and so, eg, if you tried to include nm-ip4-config.h in a libnm test, it would fail to compile because nm-test-utils.h was referring to symbols in src/nm-ip4-config.h). Fix this by changing the include guards in the non-API-stable parts of the tree: - libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H - libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__ - src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__ And likewise for all other headers. The two non-"nm"-prefixed headers, libnm/NetworkManager.h and src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely consistent with the general scheme, do still mostly make sense in isolation.
2014-08-13 14:10:11 -04:00
#ifndef __NM_SETTING_PRIVATE_H__
#define __NM_SETTING_PRIVATE_H__
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
build: refine the NETWORKMANAGER_COMPILATION define Note that: - we compile some source files multiple times. Most notably those under "shared/". - we include a default header "shared/nm-default.h" in every source file. This header is supposed to setup a common environment by defining and including parts that are commonly used. As we always include the same header, the header must behave differently depending one whether the compilation is for libnm-core, NetworkManager or libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h> depending on whether we compile a library or an application. For that, the source files need the NETWORKMANAGER_COMPILATION #define to behave accordingly. Extend the define to be composed of flags. These flags are all named NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the build are available. E.g. when building libnm-core.la itself, then WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE is not available but the internal parts are still accessible. When building nmcli, only WITH_LIBNM_CORE (the public part) is available. This granularily controls the build.
2018-01-02 13:37:06 +01:00
#if !((NETWORKMANAGER_COMPILATION) &NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_PRIVATE)
clang-format: use "IndentPPDirectives:None" instead of "BeforeHash" Subjectively, I think this looks better.
2021-07-09 08:48:48 +02:00
#error Cannot use this header.
build: refine the NETWORKMANAGER_COMPILATION define Note that: - we compile some source files multiple times. Most notably those under "shared/". - we include a default header "shared/nm-default.h" in every source file. This header is supposed to setup a common environment by defining and including parts that are commonly used. As we always include the same header, the header must behave differently depending one whether the compilation is for libnm-core, NetworkManager or libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h> depending on whether we compile a library or an application. For that, the source files need the NETWORKMANAGER_COMPILATION #define to behave accordingly. Extend the define to be composed of flags. These flags are all named NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the build are available. E.g. when building libnm-core.la itself, then WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE is not available but the internal parts are still accessible. When building nmcli, only WITH_LIBNM_CORE (the public part) is available. This granularily controls the build.
2018-01-02 13:37:06 +01:00
#endif
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#include "nm-setting.h"
libnm-core: add vlans property to bridge-port setting
2019-03-16 17:21:35 +01:00
#include "nm-setting-bridge.h"
libnm-core: rename NMConnection to/from_hash methods Rename nm_connection_to_hash() to nm_connection_to_dbus(), and nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In addition to clarifying that this is specifically the D-Bus serialization format, these names will also work better in the GDBus-based future where the serialization format is GVariant, not GHashTable. Also, move NMSettingHashFlags to nm-connection.h, and rename it NMConnectionSerializationFlags.
2014-08-06 19:35:31 -04:00
#include "nm-connection.h"
libnm-core: simplify _nm_register_setting(), register error types too Simplify the use of _nm_register_setting() by having it splice together various symbol names itself rather than requiring them to be specified explicitly, and extend it to also ensure that the type's corresponding error type is registered (allowing one to find it via g_type_from_name() if necessary).
2014-08-07 17:19:40 -04:00
#include "nm-core-enum-types.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-intern/nm-core-internal.h"
libnm-core: declare NM_SETTING_COMPARE_FLAG_INFERRABLE flag in "nm-core-internal.h" As this flag is used by NM-core, move it to nm-core-internal.h header file. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-11 18:10:43 +02:00
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: optimize NM_CONNECTION_GET_PRIVATE() for NMSimpleConnection NMConnection is a glib interface, implemented only by NMSimpleConnection and NMRemoteConnection. Inside the daemon, every NMConnection instance is always a NMSimpleConnection. Using glib interfaces has an overhead, for example NM_IS_CONNECTION() needs to search the implemented types for the pointer. And NM_CONNECTION_GET_PRIVATE() is implemented by attaching user data to the GObject instance. Both have measurable overhead. Special case them for NMSimpleConnection. This optimizes primarily the call to nm_connection_get_setting_connection(), which easily gets called millions of times. This is easily measurable.
2021-06-14 19:29:18 +02:00
typedef struct {
NMConnection *self;
NMSetting *settings[_NM_META_SETTING_TYPE_NUM];
/* D-Bus path of the connection, if any */
char *path;
} NMConnectionPrivate;
extern GTypeClass *_nm_simple_connection_class_instance;
extern int _nm_simple_connection_private_offset;
void _nm_connection_private_clear(NMConnectionPrivate *priv);
/*****************************************************************************/
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
/**
* NMSetting:
*
* The NMSetting struct contains only private data.
* It should only be accessed through the functions described below.
*/
struct _NMSetting {
GObject parent;
libnm: add code comment about preserving ABI for libnm GObject structs
2021-06-14 09:26:25 +02:00
/* In the past, this struct was public API. Preserve ABI! */
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
};
struct _NMSettingClass {
GObjectClass parent;
libnm: add code comment about preserving ABI for libnm GObject structs
2021-06-14 09:26:25 +02:00
/* In the past, this struct was public API. Preserve ABI! */
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
int (*verify)(NMSetting *setting, NMConnection *connection, GError **error);
gboolean (*verify_secrets)(NMSetting *setting, NMConnection *connection, GError **error);
GPtrArray *(*need_secrets)(NMSetting *setting);
int (*update_one_secret)(NMSetting *setting, const char *key, GVariant *value, GError **error);
gboolean (*get_secret_flags)(NMSetting * setting,
const char * secret_name,
NMSettingSecretFlags *out_flags,
GError ** error);
gboolean (*set_secret_flags)(NMSetting * setting,
const char * secret_name,
NMSettingSecretFlags flags,
GError ** error);
gboolean (*clear_secrets)(const struct _NMSettInfoSetting *sett_info,
libnm: pass around property_info instead of property_idx in NMSetting API Various NMSetting API would accept a property_idx parameter. Together with the NMSettInfoSetting instance, this was useful to find the actual NMSettInfoProperty instance. The idea was, to provide the most of the functionality. That is, if you might need the property_idx too, you had it -- after all, the property_info you could lookup yourself. However, - literally zero users care about the property_idx. The care about the property_info. - if the user really, really required the property_idx, then it is a given that it can be easily computed by (property_info - sett_info->property_infos)
2021-06-29 12:04:00 +02:00
const NMSettInfoProperty * property_info,
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
NMSetting * setting,
NMSettingClearSecretsWithFlagsFn func,
gpointer user_data);
libnm: drop NMSettingClass.compare_property()
2021-06-29 16:58:21 +02:00
void (*padding_1)(void);
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
void (*duplicate_copy_properties)(const struct _NMSettInfoSetting *sett_info,
NMSetting * src,
NMSetting * dst);
void (*enumerate_values)(const struct _NMSettInfoProperty *property_info,
NMSetting * setting,
NMSettingValueIterFn func,
gpointer user_data);
gboolean (*aggregate)(NMSetting *setting, int type_i, gpointer arg);
void (*for_each_secret)(NMSetting * setting,
const char * secret_name,
GVariant * val,
gboolean remove_non_secrets,
_NMConnectionForEachSecretFunc callback,
gpointer callback_data,
GVariantBuilder * setting_builder);
gboolean (*init_from_dbus)(NMSetting * setting,
GHashTable * keys,
GVariant * setting_dict,
GVariant * connection_dict,
guint /* NMSettingParseFlags */ parse_flags,
GError ** error);
libnm: add generic cleanup function to finalize NMSetting If all settings would be strictly be implemented as "direct" properties, we could call this from NMSetting.finalize() and be done with it. As it is, for now we cannot, so it's still cumbersome.
2021-06-28 23:51:42 +02:00
union {
gpointer padding[1];
struct {
/* Whether NMSetting.finalize() calls _nm_setting_property_finalize_direct(). Subclasses
* need to be aware of that, and currently this is opt-in.
*
* The only reason because subclasses need to be aware of this, is that they
* otherwise might clear the properties already and leave dangling pointers.
*
* Eventually all setting classes should stop touching their direct properties
* during finalize, and always let NMSetting.finalize() handle them. */
bool finalize_direct : 1;
};
};
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
const struct _NMMetaSettingInfo *setting_info;
};
/*****************************************************************************/
/**
* NMSettingIPConfig:
*/
struct _NMSettingIPConfig {
NMSetting parent;
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
/* In the past, this struct was public API. Preserve ABI! */
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
};
struct _NMSettingIPConfigClass {
NMSettingClass parent;
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
/* In the past, this struct was public API. Preserve ABI! */
union {
gpointer _dummy;
int private_offset;
};
gpointer padding[7];
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
};
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
typedef struct {
GPtrArray *dns; /* array of IP address strings */
GPtrArray *dns_search; /* array of domain name strings */
GPtrArray *dns_options; /* array of DNS options */
GPtrArray *addresses; /* array of NMIPAddress */
GPtrArray *routes; /* array of NMIPRoute */
GPtrArray *routing_rules;
GArray * dhcp_reject_servers;
char * method;
char * gateway;
char * dhcp_hostname;
char * dhcp_iaid;
gint64 route_metric;
guint dhcp_hostname_flags;
int dns_priority;
int dad_timeout;
int dhcp_timeout;
int required_timeout;
guint32 route_table;
libnm: use _nm_setting_property_define_direct_boolean() There is a new way how to implement default boolean properties. Use it.
2021-06-28 17:28:21 +02:00
bool ignore_auto_routes;
bool ignore_auto_dns;
bool dhcp_send_hostname;
bool never_default;
bool may_fail;
libnm: let NMSettingIPConfigPrivate be tracked by subclasses For our property meta data handling we require that all the meta data is associated with one GType. NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that we already have _nm_sett_info_property_override_create_array_ip_config() because the meta data must be initialized together at one place. We will require that we can find the offset for properties based on one offset per type. That is cumbersome, if NMSettingIPConfigPrivate is private itself. Simplify that, by internally sharing NMSettingIPConfigPrivate and let the subclasses embed the private data in their own private data. Optimally we would simply embed the private struct as field into NMSettingIPConfig. But that would be an ABI change as that struct was public before 1.32. Don't change ABI for now, so we have to awkwardly place it into the subclasses private data.
2021-06-28 18:14:04 +02:00
} NMSettingIPConfigPrivate;
void _nm_setting_ip_config_private_init(gpointer self, NMSettingIPConfigPrivate *priv);
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
/*****************************************************************************/
libnm: add enum for setting priorities Using plain numbers make it cumbersome to grep for setting types by priority. The only downside is, that with the enum values it is no longer obvious which value has higher or lower priority. Also, introduce NM_SETTING_PRIORITY_INVALID. This is what _nm_setting_type_get_base_type_priority() returns. For the moment it still has the same numerical value 0 as before. Later, that shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
2017-06-01 13:43:52 +02:00
NMSettingPriority _nm_setting_get_base_type_priority(NMSetting *setting);
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
int _nm_setting_compare_priority(gconstpointer a, gconstpointer b);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: add nm_meta_setting_info helpers
2021-06-11 15:28:42 +02:00
int _nmtst_nm_setting_sort(NMSetting *a, NMSetting *b);
/*****************************************************************************/
#define _nm_assert_setting_info(setting_info, gtype) \
G_STMT_START \
{ \
const NMMetaSettingInfo *_setting_info = (setting_info); \
\
if (NM_MORE_ASSERTS > 0) { \
GType _gtype = (gtype); \
\
nm_assert(_setting_info); \
nm_assert(_NM_INT_NOT_NEGATIVE(_setting_info->meta_type)); \
nm_assert(_setting_info->meta_type < _NM_META_SETTING_TYPE_NUM); \
nm_assert(_setting_info->get_setting_gtype); \
if (_gtype != 0) \
nm_assert(_setting_info->get_setting_gtype() == _gtype); \
else \
_gtype = _setting_info->get_setting_gtype(); \
nm_assert(g_type_is_a(_gtype, NM_TYPE_SETTING)); \
} \
} \
G_STMT_END
static inline const NMMetaSettingInfo *
_nm_meta_setting_info_from_class(NMSettingClass *klass)
{
const NMMetaSettingInfo *setting_info;
if (!NM_IS_SETTING_CLASS(klass))
return NULL;
setting_info = klass->setting_info;
if (!setting_info)
return NULL;
_nm_assert_setting_info(setting_info, G_OBJECT_CLASS_TYPE(klass));
return setting_info;
}
static inline const NMMetaSettingInfo *
_nm_meta_setting_info_from_gtype(GType gtype)
{
const NMMetaSettingInfo *setting_info;
setting_info = nm_meta_setting_infos_by_gtype(gtype);
if (!setting_info)
return NULL;
_nm_assert_setting_info(setting_info, gtype);
return setting_info;
}
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
/*****************************************************************************/
libnm: add _nm_setting_emit_property_changed() function Will be used next.
2019-01-20 13:49:08 +01:00
void _nm_setting_emit_property_changed(NMSetting *setting);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
typedef enum NMSettingUpdateSecretResult {
NM_SETTING_UPDATE_SECRET_ERROR = FALSE,
NM_SETTING_UPDATE_SECRET_SUCCESS_MODIFIED = TRUE,
NM_SETTING_UPDATE_SECRET_SUCCESS_UNCHANGED = 2,
} NMSettingUpdateSecretResult;
NMSettingUpdateSecretResult
_nm_setting_update_secrets(NMSetting *setting, GVariant *secrets, GError **error);
libnm: merge _nm_setting_clear_secrets() and *_with_flags()
2019-01-13 20:47:05 +01:00
gboolean _nm_setting_clear_secrets(NMSetting * setting,
NMSettingClearSecretsWithFlagsFn func,
gpointer user_data);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: add NM_SETTING_PARAM_NONE define This completes other NM_SETTING_PARAM_* flags.
2021-06-18 00:01:30 +02:00
/*****************************************************************************/
#define NM_SETTING_PARAM_NONE 0
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/* The property of the #NMSetting should be considered during comparisons that
* use the %NM_SETTING_COMPARE_FLAG_INFERRABLE flag. Properties that don't have
* this flag, are ignored when doing an infrerrable comparison. This flag should
* be set on all properties that are read from the kernel or the system when a
* connection is generated. eg, IP addresses/routes can be read from the
* kernel, but the 'autoconnect' property cannot, so
* %NM_SETTING_IP4_CONFIG_ADDRESSES gets the INFERRABLE flag, but
* %NM_SETTING_CONNECTION_AUTOCONNECT would not.
*
* This flag should not be used with properties where the default cannot be
* read separately from the current value, like MTU or wired duplex mode.
*/
#define NM_SETTING_PARAM_INFERRABLE (1 << (4 + G_PARAM_USER_SHIFT))
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
/* This is a legacy property, which clients should not send to the daemon. */
#define NM_SETTING_PARAM_LEGACY (1 << (5 + G_PARAM_USER_SHIFT))
libnm: mark properties that take effect immediately on active connection (REAPPLY_IMMEDIATELY) The flag is still unused.
2015-09-18 17:21:34 +02:00
/* When a connection is active and gets modified, usually the change
* to the settings-connection does not propagate automatically to the
* applied-connection of the device. For certain properties like the
* firewall zone and the metered property, this is different.
*
* Such fields can be ignored during nm_connection_compare() with the
* NMSettingCompareFlag NM_SETTING_COMPARE_FLAG_IGNORE_REAPPLY_IMMEDIATELY.
*/
#define NM_SETTING_PARAM_REAPPLY_IMMEDIATELY (1 << (6 + G_PARAM_USER_SHIFT))
libnm: don't special case "vpn.secrets" property in property_to_dbus() "nm-setting.c" (and property_to_dbus()) should stay independent of actualy settings implementations. Instead, the property-info should control the behavior. What I like about this change is also that the generic handling is not a flags "handle_secrets_for_vpn", but it just says to skip checking the param-spec flags and directly call the to_dbus_fcn(). It's just a generally useful thing to do, to let the to_dbus_fcn() function also handle checking the property flags. The fact that only vpn.secrets properties uses this for a certain pupose, is abstracted in a way that makes sense.
2019-09-24 18:25:00 +02:00
/* property_to_dbus() should ignore the property flags, and instead always calls to_dbus_fcn()
*/
#define NM_SETTING_PARAM_TO_DBUS_IGNORE_FLAGS (1 << (7 + G_PARAM_USER_SHIFT))
libnm: explicitly ignore to-dbus for "name" property NM_SETTING_NAME is also a GObject property, but it's not supposed to be serialized to/from D-Bus. It also is irrelevant for comparison. Hence, it's operations are all NOPs. Make an explicit property type for that case instead of checking the GParamSpec flags.
2021-06-29 22:28:07 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_setting_name;
libnm: deduplicate NMSettInfoPropertType instances There is no need to keep duplicate instances. Before we had 89 distinct property types, now there are 49.
2019-09-22 10:57:57 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_interface_name;
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_ignore_i;
extern const NMSettInfoPropertType nm_sett_info_propert_type_deprecated_ignore_u;
extern const NMSettInfoPropertType nm_sett_info_propert_type_plain_i;
extern const NMSettInfoPropertType nm_sett_info_propert_type_plain_u;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_boolean;
libnm: add direct_offset for uint32 properties And as example, implement NMSettingVrf.table this way. This also makes all properties of NMSettingVrf implemened as "direct" properties, and we can drop the explicit getter/setters.
2021-06-29 07:57:41 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_uint32;
libnm: add direct_offset for string properties And, as an example used for property "connection.stable-id".
2021-06-28 19:17:19 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_string;
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
NMSettingVerifyResult
_nm_setting_verify(NMSetting *setting, NMConnection *connection, GError **error);
libnm: add nm_setting_verify_secrets() and nm_connection_verify_secrets() for verifying the secrets, because it is not done in plain nm_setting_verify(). For simple verification of free-form string secrets, _nm_setting_verify_secret_string() helper is used.
2015-11-10 14:36:20 +01:00
gboolean _nm_setting_verify_secret_string(const char *str,
const char *setting_name,
const char *property,
GError ** error);
libnm,core: add _nm_connection_aggregate() to replace nm_connection_for_each_setting_value() We should no longer use nm_connection_for_each_setting_value() and nm_setting_for_each_value(). It's fundamentally broken as it does not work with properties that are not backed by a GObject property and it cannot be fixed because it is public API. Add an internal function _nm_connection_aggregate() to replace it. Compare the implementation of the aggregation functionality inside libnm with the previous two checks for secret-flags that it replaces: - previous approach broke abstraction and require detailed knowledge of secret flags. Meaning, they must special case NMSettingVpn and GObject-property based secrets. If we implement a new way for implementing secrets (like we will need for WireGuard), then this the new way should only affect libnm-core, not require changes elsewhere. - it's very inefficient to itereate over all settings. It involves cloning and sorting the list of settings, and retrieve and clone all GObject properties. Only to look at secret properties alone. _nm_connection_aggregate() is supposed to be more flexible then just the two new aggregate types that perform a "find-any" search. The @arg argument and boolean return value can suffice to implement different aggregation types in the future. Also fixes the check of NMAgentManager for secret flags for VPNs (NM_CONNECTION_AGGREGATE_ANY_SYSTEM_SECRET_FLAGS). A secret for VPNs is a property that either has a secret or a secret-flag. The previous implementation would only look at present secrets and check their flags. It wouldn't check secret-flags that are NM_SETTING_SECRET_FLAG_NONE, but have no secret.
2019-01-04 11:28:27 +01:00
gboolean _nm_setting_aggregate(NMSetting *setting, NMConnectionAggregateType type, gpointer arg);
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-07 17:05:10 +02:00
gboolean _nm_setting_slave_type_is_valid(const char *slave_type, const char **out_port_type);
libnm: add _nm_setting_compare_flags_check() helper
2021-06-29 18:12:56 +02:00
gboolean _nm_setting_compare_flags_check(const GParamSpec * param_spec,
NMSettingCompareFlags flags,
NMSetting * set_a,
NMSetting * set_b);
libnm: add special ignore function for NMSettInfoPropertType.compare_fcn()
2021-06-29 17:03:37 +02:00
NMTernary _nm_setting_property_compare_fcn_ignore(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
libnm: implement "direct" properties for compare_fcn()
2021-06-29 18:18:06 +02:00
NMConnection * con_a,
NMSetting * set_a,
NMConnection * con_b,
NMSetting * set_b,
NMSettingCompareFlags flags);
NMTernary _nm_setting_property_compare_fcn_direct(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
libnm: add special ignore function for NMSettInfoPropertType.compare_fcn()
2021-06-29 17:03:37 +02:00
NMConnection * con_a,
NMSetting * set_a,
NMConnection * con_b,
NMSetting * set_b,
NMSettingCompareFlags flags);
libnm: add compare_fcn() to property meta data So far, we only have NMSettingClass.compare_property() hook. The ugliness is that this hook is per-setting, when basically all implementations only compare one property. It feels cleaner to have a per-property hook and call that consistently. In step one, we give all properties (the same) compare_fcn() implementation, which delegates to the existing NMSettingClass.compare_property(). In a second step, this will be untangled. There is one problem with this approach: NMSettInfoPropertType grows by one pointer size, and we have potentially many such types. That should be addressed by unifying types in the future.
2021-06-29 14:23:16 +02:00
NMTernary _nm_setting_property_compare_fcn_default(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMConnection * con_a,
NMSetting * set_a,
NMConnection * con_b,
NMSetting * set_b,
NMSettingCompareFlags flags);
libnm: add generic GObject property getter/setter If we only have simple, direct properties, then we have all the information we need for a generic get_property()/set_property() implmenentation.
2021-06-28 20:48:40 +02:00
void _nm_setting_property_get_property_direct(GObject * object,
guint prop_id,
GValue * value,
GParamSpec *pspec);
void _nm_setting_property_set_property_direct(GObject * object,
guint prop_id,
const GValue *value,
GParamSpec * pspec);
libnm: explicitly ignore to-dbus for "name" property NM_SETTING_NAME is also a GObject property, but it's not supposed to be serialized to/from D-Bus. It also is irrelevant for comparison. Hence, it's operations are all NOPs. Make an explicit property type for that case instead of checking the GParamSpec flags.
2021-06-29 22:28:07 +02:00
GVariant *_nm_setting_property_to_dbus_fcn_ignore(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty * property_info,
NMConnection * connection,
NMSetting * setting,
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
libnm: let all property types implement to_dbus_fcn() handler If a property can be converted to D-Bus, then always set the to_dbus_fcn() handler. The only caller of to_dbus_fcn() is property_to_dbus(), so this means that property_to_dbus() has no more default implementation and always delegates to to_dbus_fcn(). The code is easier to understand if all properties implement to_dbus_fcn() the same way. Also, there is supposed to be a split between NMSettInfoProperty (info about the property) and NMSettInfoPropertType (the type). The idea is that each property (obviously) requires its distinct NMSettInfoProperty, but they can share a common type implementation. With NMSettInfoPropertType.gprop_to_dbus_fcn that is often violated because many properties that implement NMSettInfoPropertType.gprop_to_dbus_fcn require a special type implementation. As such, gprop_to_dbus_fcn should be part of the property info and not the property type. The first step towards that is unifying all properties to use to_dbus_fcn().
2021-06-18 08:59:12 +02:00
GVariant *_nm_setting_property_to_dbus_fcn_gprop(const NMSettInfoSetting * sett_info,
libnm: pass around property_info instead of property_idx in NMSetting API Various NMSetting API would accept a property_idx parameter. Together with the NMSettInfoSetting instance, this was useful to find the actual NMSettInfoProperty instance. The idea was, to provide the most of the functionality. That is, if you might need the property_idx too, you had it -- after all, the property_info you could lookup yourself. However, - literally zero users care about the property_idx. The care about the property_info. - if the user really, really required the property_idx, then it is a given that it can be easily computed by (property_info - sett_info->property_infos)
2021-06-29 12:04:00 +02:00
const NMSettInfoProperty * property_info,
libnm: let all property types implement to_dbus_fcn() handler If a property can be converted to D-Bus, then always set the to_dbus_fcn() handler. The only caller of to_dbus_fcn() is property_to_dbus(), so this means that property_to_dbus() has no more default implementation and always delegates to to_dbus_fcn(). The code is easier to understand if all properties implement to_dbus_fcn() the same way. Also, there is supposed to be a split between NMSettInfoProperty (info about the property) and NMSettInfoPropertType (the type). The idea is that each property (obviously) requires its distinct NMSettInfoProperty, but they can share a common type implementation. With NMSettInfoPropertType.gprop_to_dbus_fcn that is often violated because many properties that implement NMSettInfoPropertType.gprop_to_dbus_fcn require a special type implementation. As such, gprop_to_dbus_fcn should be part of the property info and not the property type. The first step towards that is unifying all properties to use to_dbus_fcn().
2021-06-18 08:59:12 +02:00
NMConnection * connection,
NMSetting * setting,
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
GVariant *_nm_setting_property_to_dbus_fcn_direct(const NMSettInfoSetting * sett_info,
libnm: pass around property_info instead of property_idx in NMSetting API Various NMSetting API would accept a property_idx parameter. Together with the NMSettInfoSetting instance, this was useful to find the actual NMSettInfoProperty instance. The idea was, to provide the most of the functionality. That is, if you might need the property_idx too, you had it -- after all, the property_info you could lookup yourself. However, - literally zero users care about the property_idx. The care about the property_info. - if the user really, really required the property_idx, then it is a given that it can be easily computed by (property_info - sett_info->property_infos)
2021-06-29 12:04:00 +02:00
const NMSettInfoProperty * property_info,
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
NMConnection * connection,
NMSetting * setting,
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
libnm: always set from_dbus_fcn() property hook When looking at a property, it should always be clear how it is handled. Also the "default" action should be an explicit hook. Add _nm_setting_property_from_dbus_fcn_gprop() and set that as from_dbus_fcn() callback to handle the "default" case which us build around g_object_set_property(). While this adds lines of code, I think it makes the code easier to understand. Basically, to convert a GVariant to a property, now all properties call their from_dbus_fcn() handler, there is no special casing. And the gprop-hook is only called for properties that are using _nm_setting_property_from_dbus_fcn_gprop(). So, you can reason about these two functions at separate layers.
2021-06-30 00:05:49 +02:00
gboolean _nm_setting_property_from_dbus_fcn_ignore(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMSetting * setting,
GVariant * connection_dict,
GVariant * value,
NMSettingParseFlags parse_flags,
GError ** error);
gboolean _nm_setting_property_from_dbus_fcn_gprop(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMSetting * setting,
GVariant * connection_dict,
GVariant * value,
NMSettingParseFlags parse_flags,
GError ** error);
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
GVariant *_nm_setting_to_dbus(NMSetting * setting,
libnm-core: add dbus-only properties to NMSettingClass Add _nm_setting_class_add_dbus_only_property(), for declaring properties that appear in the D-Bus serialization, but which don't correspond to GObject properties. Since some property overrides will require examining settings other than the setting that they are on (eg, the value of 802-11-wireless.security depends on whether an NMSettingWirelessSecurity setting is present, and NMSettingConnection:interface-name might sometimes be set from, eg, bond.interface-name), we also update _nm_setting_to_dbus() to take the full NMConnection as an argument, and _nm_setting_new_from_dbus() to take the full connection hash. Additionally, with some deprecated properties, we'll want to validate them on construction, but we don't need to keep the value around after that. So allow _nm_setting_new_from_dbus() to return a verification error directly, so we don't need to store the value until the verify() call.
2014-07-29 18:25:10 -04:00
NMConnection * connection,
libnm: add nm_connection_to_dbus_full() with options argument No options are implemented yet.
2019-06-27 09:07:16 +02:00
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
libnm-core: make the NMSetting hash methods private Make nm_setting_to_hash() and nm_setting_new_from_hash() private, and remove the public nm_setting_update_secrets() wrapper around the existing private _nm_setting_update_secrets(). These functions should really only be called from the corresponding NMConnection-level methods, and in particular, with certain compatibility properties in the future, we will need to consider the entire connection all at once when setting properties, so it won't make sense to serialize/deserialize a single setting in isolation.
2014-08-04 11:23:11 -04:00
libnm-core: rename NMConnection to/from_hash methods Rename nm_connection_to_hash() to nm_connection_to_dbus(), and nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In addition to clarifying that this is specifically the D-Bus serialization format, these names will also work better in the GDBus-based future where the serialization format is GVariant, not GHashTable. Also, move NMSettingHashFlags to nm-connection.h, and rename it NMConnectionSerializationFlags.
2014-08-06 19:35:31 -04:00
NMSetting *_nm_setting_new_from_dbus(GType setting_type,
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
GVariant * setting_dict,
GVariant * connection_dict,
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() In some situations, we want strict checking of errors, for example when NetworkManager receives a new connection from a client, the connection must make sense as a whole (and since NetworkManager service is backward compatible to the clients and not the other way around, there is no excuse for sending invalid data to the server). In other situations, we want a best-effort behavior. Like when NetworkManager sends a connection to its clients, those clients want to extract as many properties as they understand, but in order to be forward compatible against newer server versions, invalid or unknown properties must be accepted. Previously, a mixture of both was done. Some issues caused a failure to create a new NMSetting, other invalid parts were just silently ignored or triggered a g_warning() in glib. Now allow for both. When doing strict-validation, be more strict and reject all unknown properties and catch when the user sets an invalid argument. On the other hand, allow for a best-effort mode that effectively cannot fail and will return a new NMSetting instance. For now, add NMSettingParseFlags so that the caller can choose the old behavior, strict parsing, or best effort. This patch doesn't have any externally visible change except that no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
NMSettingParseFlags parse_flags,
libnm-core: add dbus-only properties to NMSettingClass Add _nm_setting_class_add_dbus_only_property(), for declaring properties that appear in the D-Bus serialization, but which don't correspond to GObject properties. Since some property overrides will require examining settings other than the setting that they are on (eg, the value of 802-11-wireless.security depends on whether an NMSettingWirelessSecurity setting is present, and NMSettingConnection:interface-name might sometimes be set from, eg, bond.interface-name), we also update _nm_setting_to_dbus() to take the full NMConnection as an argument, and _nm_setting_new_from_dbus() to take the full connection hash. Additionally, with some deprecated properties, we'll want to validate them on construction, but we don't need to keep the value around after that. So allow _nm_setting_new_from_dbus() to return a verification error directly, so we don't need to store the value until the verify() call.
2014-07-29 18:25:10 -04:00
GError ** error);
libnm: cleanup secret-flags setter and getter There are 3 kinds of secret flag implementations: 1) regular properties have a GObject property and a corresponding "-flags" property. 2) NMSettingVpn handles this entirely differently 3) NMSettingWirelessSecurity's WEP keys, where the secret keys share a flags property that does not follow the same naming scheme as 1). The getter and setter had a boolean "verifiy_secret", only to handle 3). Drop that parameter. Don't let NMSettingWirelessSecurity call the parent's implementation for WEP keys. Just let it handle it directly.
2019-01-06 13:49:46 +01:00
gboolean _nm_setting_property_is_regular_secret(NMSetting *setting, const char *secret_name);
gboolean _nm_setting_property_is_regular_secret_flags(NMSetting * setting,
const char *secret_flags_name);
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
/*****************************************************************************/
libnm: support lookup of property-info by param-spec We also need to find efficiently the property-info for a given GParamSpec. Add a lookup index for that.
2021-06-28 23:00:21 +02:00
const NMSettInfoProperty *
_nm_sett_info_property_lookup_by_param_spec(const NMSettInfoSetting *sett_info,
const GParamSpec * param_spec);
libnm: pre-allocate buffer in _nm_sett_info_property_override_create_array() The buffer created here is only temporary to construct the property info by _nm_setting_class_commit_full(). We can afford to allocate more than necessary, if we thereby avoid several reallocations.
2021-06-21 14:52:47 +02:00
static inline GArray *
_nm_sett_info_property_override_create_array_sized(guint reserved_size)
{
return g_array_sized_new(FALSE, FALSE, sizeof(NMSettInfoProperty), reserved_size);
}
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
static inline GArray *
_nm_sett_info_property_override_create_array(void)
{
libnm: pre-allocate buffer in _nm_sett_info_property_override_create_array() The buffer created here is only temporary to construct the property info by _nm_setting_class_commit_full(). We can afford to allocate more than necessary, if we thereby avoid several reallocations.
2021-06-21 14:52:47 +02:00
/* pre-allocate a relatively large buffer to avoid frequent re-allocations.
* Note that the buffer is only short-lived and will be destroyed by
libnm: extend NMSettInfoSetting with an offset to the private data NMSetting instances either have no private data, they use g_type_add_class_private(), or they embed the private data in the NMSetting struct. In all cases, we can find the private data at a fixed offset. Track that offset in the NMSettInfoSetting meta data. This will be useful, because properties really are stored in simple fields, like a boolean property can be stored in a "bool" field. We will extend the property meta data to track the offset of this property field, but we also need to know where the offset starts.
2021-06-28 14:53:16 +02:00
* _nm_setting_class_commit(). */
libnm: pre-allocate buffer in _nm_sett_info_property_override_create_array() The buffer created here is only temporary to construct the property info by _nm_setting_class_commit_full(). We can afford to allocate more than necessary, if we thereby avoid several reallocations.
2021-06-21 14:52:47 +02:00
return _nm_sett_info_property_override_create_array_sized(20);
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
}
GArray *_nm_sett_info_property_override_create_array_ip_config(void);
libnm: extend NMSettInfoSetting with an offset to the private data NMSetting instances either have no private data, they use g_type_add_class_private(), or they embed the private data in the NMSetting struct. In all cases, we can find the private data at a fixed offset. Track that offset in the NMSettInfoSetting meta data. This will be useful, because properties really are stored in simple fields, like a boolean property can be stored in a "bool" field. We will extend the property meta data to track the offset of this property field, but we also need to know where the offset starts.
2021-06-28 14:53:16 +02:00
void _nm_setting_class_commit(NMSettingClass * setting_class,
NMMetaSettingType meta_type,
const NMSettInfoSettDetail *detail,
GArray * properties_override,
gint16 private_offset);
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
libnm: add generic-data for implementing NMSetting Add a new way how NMSetting subclasses can be implemented. Currently, most NMSetting implementations realize all their properties via GObject properties. That has some downsides: - the biggest one, is the large effort to add new properties. Most of them are implemented on a one-by-one basis and they come with additional API (like native getter functions). It makes it cumbersome to add more properties. - for certain properties, it's hard to encode them entirely in a GObject property. That results in unusable API like NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS, NM_SETTING_USER_DATA. These complex valued properties only exist, because we currently always need GObject properties to even implement simple functionality. For example, nm_setting_duplicate() is entirely implemented via nm_setting_enumerate_values(), which can only iterate GObject properies. There is no reason why this is necessary. Note also how nmcli badly handles bond options and VPN data. That is only a shortcoming of nmcli and wouldn't need to be that way. But it happend, because we didn't keep an open mind that settings might be more than just accessing GObject properties. - a major point of NMSetting is to convert to/from a GVariant from the D-Bus API. As NMSetting needs to squeeze all values into the static GObject structure, there is no place to encode invalid or unknown properties. Optimally, _nm_setting_new_from_dbus() does not loose any information and a subsequent _nm_setting_to_dbus() can restore the original variant. That is interesting, because we want that an older libnm client can talk to a newer NetworkManager version. The client needs to handle unknown properties gracefully to stay forward compatible. However, it also should not just drop the properties on the floor. Note however, optimally we want that nm_setting_verify() still can reject settings that have such unknown/invalid values. So, it should be possible to create an NMSetting instance without error or loosing information. But verify() should be usable to identify such settings as invalid. They also have a few upsides. - libnm is heavily oriented around GObject. So, we generate our nm-settings manual based on the gtk-doc. Note however, how we fail to generate a useful manual for bond.options. Also note, that there is no reason we couldn't generate great documentation, even if the properties are not GObject properties. - GObject properties do give some functionality like meta-data, data binding and notification. However, the meta-data is not sufficient on its own. Note how keyfile and nmcli need extensive descriptor tables on top of GObject properties, to make this useful. Note how GObject notifications for NMSetting instances are usually not useful, aside for data binding like nmtui does. Also note how NMSettingBond already follows a different paradigm than using GObject properties. Nowdays, NMSettingBond is considered a mistake (related bug rh#1032808). Many ideas of NMSettingBond are flawed, like exposing an inferiour API that reduces everything to a string hash. Also, it only implemented the options hash inside NMSettingBond. That means, if we would consider this a good style, we would have to duplicate this approach in each new setting implementation. Add a new style to track data for NMSetting subclasses. It keeps an internal hash table with all GVariant properies. Also, the functionality is hooked into NMSetting base class, so all future subclasses that follow this way, can benefit from this. This approach has a few similiarties with NMSettingBond, but avoids its flaws. With this, we also no longer need GObject properties (if we would also implement generating useful documentation based on non-gkt-doc). They may be added as accessors if they are useful, but there is no need for them. Also, handling the properties as a hash of variants invites for a more generic approach when handling them. While we still could add accessors that operate on a one-by-one bases, this leads to a more generic usage where we apply common functionality to a set of properties. Also, this is for the moment entirely internal and an implementation detail. It's entirely up to the NMSetting subclass to make use of this new style. Also, there are little hooks for the subclass available. If they turn out to be necessary, they might be added. However, for the moment, the functionality is restricted to what is useful and necessary.
2018-07-27 10:05:40 +02:00
#define NM_SETT_INFO_SETT_GENDATA(...) \
({ \
static const NMSettInfoSettGendata _g = {__VA_ARGS__}; \
\
&_g; \
})
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
#define NM_SETT_INFO_SETT_DETAIL(...) (&((const NMSettInfoSettDetail){__VA_ARGS__}))
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_*_INIT() macros The advantage is that we use similar macros for initializing the static structs like const NMSettInfoPropertType nm_sett_info_propert_type_cloned_mac_address; and the ad-hoc locations that use NM_SETT_INFO_PROPERT_TYPE(). The former exist for property types that are used more than once. The latter exist for convenience, where a property type is implemented at only one place. Also, there are few direct references to _nm_setting_property_to_dbus_fcn_gprop(). all users use NM_SETT_INFO_PROPERT_TYPE_GPROP() or NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT().
2021-06-18 09:59:40 +02:00
#define NM_SETT_INFO_PROPERT_TYPE_DBUS_INIT(_dbus_type, ...) \
{ \
.dbus_type = _dbus_type, __VA_ARGS__ \
}
libnm: add compare_fcn() to property meta data So far, we only have NMSettingClass.compare_property() hook. The ugliness is that this hook is per-setting, when basically all implementations only compare one property. It feels cleaner to have a per-property hook and call that consistently. In step one, we give all properties (the same) compare_fcn() implementation, which delegates to the existing NMSettingClass.compare_property(). In a second step, this will be untangled. There is one problem with this approach: NMSettInfoPropertType grows by one pointer size, and we have potentially many such types. That should be addressed by unifying types in the future.
2021-06-29 14:23:16 +02:00
#define NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT(_dbus_type, ...) \
NM_SETT_INFO_PROPERT_TYPE_DBUS_INIT(_dbus_type, \
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_gprop, \
__VA_ARGS__)
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_*_INIT() macros The advantage is that we use similar macros for initializing the static structs like const NMSettInfoPropertType nm_sett_info_propert_type_cloned_mac_address; and the ad-hoc locations that use NM_SETT_INFO_PROPERT_TYPE(). The former exist for property types that are used more than once. The latter exist for convenience, where a property type is implemented at only one place. Also, there are few direct references to _nm_setting_property_to_dbus_fcn_gprop(). all users use NM_SETT_INFO_PROPERT_TYPE_GPROP() or NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT().
2021-06-18 09:59:40 +02:00
#define NM_SETT_INFO_PROPERT_TYPE(init) \
({ \
static const NMSettInfoPropertType _g = init; \
\
&_g; \
libnm: refactor NMSettInfoProperty to save memory for simple properties In total, we register 447 property informations. Out of these, 326 are plain, GObject property based without special implementations. The NMSettInfoProperty had all function pointers directly embedded, currently this amounts to 5 function pointers and the "dbus_type" field. That means, at runtime we have 326 times trivial implementations with waste 326*6*8 bytes of NULL pointers. We can compact these by moving them to a separate structure. Before: 447 * 5 function pointers 447 * "dbus_type" pointer = 2682 pointers After: 447 * 1 pointers (for NMSettInfoProperty.property_type) 89 * 6 pointers (for the distinct NMSettInfoPropertType data) = 981 pointers So, in total this saves 13608 byes of runtime memory (on 64 bit arch). The 89 NMSettInfoPropertType instances are the remaining distinct instances. Note that every NMSettInfoProperty has a "property_type" pointer, but most of them are shared. That is because the underlying type and the operations are the same. Also nice is that the NMSettInfoPropertType are actually constant, static fields and initialized very early. This change also makes sense form a design point of view. Previously, NMSettInfoProperty contained both per-property data (the "name") but also the behavior. Now, the "behavioral" part is moved to a separate structure (where it is also shared). That means, the parts that are concerned with the type of the property (the behavior) are separate from the actual data of the property.
2019-09-22 08:53:06 +02:00
})
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
#define NM_SETT_INFO_PROPERT_TYPE_DBUS(_dbus_type, ...) \
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_*_INIT() macros The advantage is that we use similar macros for initializing the static structs like const NMSettInfoPropertType nm_sett_info_propert_type_cloned_mac_address; and the ad-hoc locations that use NM_SETT_INFO_PROPERT_TYPE(). The former exist for property types that are used more than once. The latter exist for convenience, where a property type is implemented at only one place. Also, there are few direct references to _nm_setting_property_to_dbus_fcn_gprop(). all users use NM_SETT_INFO_PROPERT_TYPE_GPROP() or NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT().
2021-06-18 09:59:40 +02:00
NM_SETT_INFO_PROPERT_TYPE(NM_SETT_INFO_PROPERT_TYPE_DBUS_INIT(_dbus_type, __VA_ARGS__))
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_*_INIT() macros The advantage is that we use similar macros for initializing the static structs like const NMSettInfoPropertType nm_sett_info_propert_type_cloned_mac_address; and the ad-hoc locations that use NM_SETT_INFO_PROPERT_TYPE(). The former exist for property types that are used more than once. The latter exist for convenience, where a property type is implemented at only one place. Also, there are few direct references to _nm_setting_property_to_dbus_fcn_gprop(). all users use NM_SETT_INFO_PROPERT_TYPE_GPROP() or NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT().
2021-06-18 09:59:40 +02:00
#define NM_SETT_INFO_PROPERT_TYPE_GPROP(_dbus_type, ...) \
NM_SETT_INFO_PROPERT_TYPE(NM_SETT_INFO_PROPERT_TYPE_GPROP_INIT(_dbus_type, __VA_ARGS__))
libnm: let all property types implement to_dbus_fcn() handler If a property can be converted to D-Bus, then always set the to_dbus_fcn() handler. The only caller of to_dbus_fcn() is property_to_dbus(), so this means that property_to_dbus() has no more default implementation and always delegates to to_dbus_fcn(). The code is easier to understand if all properties implement to_dbus_fcn() the same way. Also, there is supposed to be a split between NMSettInfoProperty (info about the property) and NMSettInfoPropertType (the type). The idea is that each property (obviously) requires its distinct NMSettInfoProperty, but they can share a common type implementation. With NMSettInfoPropertType.gprop_to_dbus_fcn that is often violated because many properties that implement NMSettInfoPropertType.gprop_to_dbus_fcn require a special type implementation. As such, gprop_to_dbus_fcn should be part of the property info and not the property type. The first step towards that is unifying all properties to use to_dbus_fcn().
2021-06-18 08:59:12 +02:00
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
#define NM_SETT_INFO_PROPERTY(...) (&((const NMSettInfoProperty){__VA_ARGS__}))
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
gboolean _nm_properties_override_assert(const NMSettInfoProperty *prop_info);
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
libnm: cleanup _properties_override_add*() functions
2019-09-22 15:23:41 +02:00
static inline void
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override(GArray *properties_override, const NMSettInfoProperty *prop_info)
libnm: cleanup _properties_override_add*() functions
2019-09-22 15:23:41 +02:00
{
nm_assert(properties_override);
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
nm_assert(_nm_properties_override_assert(prop_info));
libnm: cleanup _properties_override_add*() functions
2019-09-22 15:23:41 +02:00
g_array_append_vals(properties_override, prop_info, 1);
}
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
#define _nm_properties_override_gobj(properties_override, \
p_param_spec, \
p_property_type, \
... /* extra NMSettInfoProperty fields */) \
_nm_properties_override((properties_override), \
NM_SETT_INFO_PROPERTY(.name = NULL, \
.param_spec = (p_param_spec), \
.property_type = (p_property_type), \
libnm: move gprop_to_dbus_fcn hook to NMSettInfoProperty For each property we have meta data in form of NMSettInfoProperty. Each meta data also has a NMSettInfoProperty.property_type (NMSettInfoPropertType). The property type is supposed to define common behaviors for properties, while the property meta data has individual properties. The idea is that several properties can share the same property-type, and that per-property meta data is part of NMSettInfoProperty. The distinction is not very strong, but note that all remaining uses of NMSettInfoPropertType.gprop_to_dbus_fcn were part of a property type that was only used for one single property. That lack of reusability hints to a wrong use. Move gprop_to_dbus_fcn to the property meta data as a new field NMSettInfoProperty.to_dbus_data. Note that NMSettInfoPropertType.gprop_from_dbus_fcn still suffers from the same problem. But the from-dbus side is not yet addressed.
2021-06-18 10:36:17 +02:00
__VA_ARGS__))
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
#define _nm_properties_override_dbus(properties_override, p_name, p_property_type) \
_nm_properties_override( \
(properties_override), \
NM_SETT_INFO_PROPERTY(.name = ("" p_name ""), .property_type = (p_property_type), ))
libnm: deduplicate NMSettInfoPropertType instances There is no need to keep duplicate instances. Before we had 89 distinct property types, now there are 49.
2019-09-22 10:57:57 +02:00
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
/*****************************************************************************/
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
2021-06-28 17:04:37 +02:00
/* Define "direct" properties. These are properties that have a GParamSpec and
* NMSettInfoPropertType.direct_type != NM_VALUE_TYPE_NONE.
*
* With this, the location of the data is known at
*
* _nm_setting_get_private(setting, sett_info, property_info->direct_offset)
*
* which allows to generically handle the property operations (like get, set, compare).
*/
#define _nm_setting_property_define_direct_boolean(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
default_value, \
param_flags, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
G_STMT_START \
{ \
const gboolean _default_value = (default_value); \
GParamSpec * _param_spec; \
\
G_STATIC_ASSERT( \
!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_FUZZY_IGNORE | NM_SETTING_PARAM_INFERRABLE \
| NM_SETTING_PARAM_REAPPLY_IMMEDIATELY))); \
\
nm_assert(NM_IN_SET(_default_value, 0, 1)); \
\
_param_spec = \
g_param_spec_boolean("" prop_name "", \
"", \
"", \
_default_value, \
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_boolean, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(bool, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
/*****************************************************************************/
libnm-core: add _nm_setting_class_transform_property() Add a new kind of setting property override, for indicating that a property exists in both the NMSetting and the D-Bus representation, but in different formats, requiring conversion from one to the other. Also, if a property is transformable, then compare the transformed forms in nm_setting_compare() (since the D-Bus property types have more metadata built-in).
2014-07-30 10:46:24 -04:00
libnm: add direct_offset for uint32 properties And as example, implement NMSettingVrf.table this way. This also makes all properties of NMSettingVrf implemened as "direct" properties, and we can drop the explicit getter/setters.
2021-06-29 07:57:41 +02:00
#define _nm_setting_property_define_direct_uint32(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
min_value, \
max_value, \
default_value, \
param_flags, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
G_STMT_START \
{ \
GParamSpec *_param_spec; \
\
G_STATIC_ASSERT( \
!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_FUZZY_IGNORE | NM_SETTING_PARAM_INFERRABLE))); \
G_STATIC_ASSERT((min_value) <= (guint64) G_MAXUINT32); \
G_STATIC_ASSERT((max_value) <= (guint64) G_MAXUINT32); \
G_STATIC_ASSERT((default_value) <= (guint64) G_MAXUINT32); \
\
_param_spec = \
g_param_spec_uint("" prop_name "", \
"", \
"", \
(min_value), \
(max_value), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_uint32, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(guint32, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
/*****************************************************************************/
libnm: add generic cleanup function to finalize NMSetting If all settings would be strictly be implemented as "direct" properties, we could call this from NMSetting.finalize() and be done with it. As it is, for now we cannot, so it's still cumbersome.
2021-06-28 23:51:42 +02:00
#define _nm_setting_property_define_direct_string_full(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
param_flags, \
property_type, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
G_STMT_START \
{ \
GParamSpec * _param_spec; \
const NMSettInfoPropertType *_property_type = (property_type); \
\
G_STATIC_ASSERT(!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_SECRET | NM_SETTING_PARAM_FUZZY_IGNORE \
| NM_SETTING_PARAM_INFERRABLE \
| NM_SETTING_PARAM_REAPPLY_IMMEDIATELY))); \
\
nm_assert(_property_type); \
nm_assert(g_variant_type_equal(_property_type->dbus_type, "s")); \
nm_assert(_property_type->direct_type == NM_VALUE_TYPE_STRING); \
nm_assert(_property_type->to_dbus_fcn == _nm_setting_property_to_dbus_fcn_direct); \
\
_param_spec = \
g_param_spec_string("" prop_name "", \
"", \
"", \
NULL, \
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
_property_type, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(char *, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
libnm: add direct_offset for string properties And, as an example used for property "connection.stable-id".
2021-06-28 19:17:19 +02:00
G_STMT_END
#define _nm_setting_property_define_direct_string(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
param_flags, \
private_struct_type, \
private_struct_field, \
libnm: add generic cleanup function to finalize NMSetting If all settings would be strictly be implemented as "direct" properties, we could call this from NMSetting.finalize() and be done with it. As it is, for now we cannot, so it's still cumbersome.
2021-06-28 23:51:42 +02:00
... /* extra NMSettInfoProperty fields */) \
libnm: add direct_offset for string properties And, as an example used for property "connection.stable-id".
2021-06-28 19:17:19 +02:00
_nm_setting_property_define_direct_string_full((properties_override), \
(obj_properties), \
prop_name, \
(prop_id), \
(param_flags), \
&nm_sett_info_propert_type_direct_string, \
private_struct_type, \
private_struct_field, \
__VA_ARGS__)
libnm: extend to_dbus_fcn() property type for efficiently converting boolean property Most of our NMSetting properties are based around GObject properties, and thus the tooling to convert a NMSetting to/from GVariant consists of getting/setting a GValue. We can do better. For most of such properties we also define a C getter function, which we can call with less overhead. All we need is to hook the C getter with the property meta data. As example, implement it for "connection.autoconnect". The immediate goal of this is to reduce the overhead of to_dbus. But note that also for comparison of two properties, there is the default implementation which is used by the majority of properties. This implementation converts the properties first to GVariant (via to_dbus_fcn) and then compares the variants. What this commit also does, is to hook up the property meta data with the C-getters. This is one step towards also more efficiently compare properties using the naive C getters. Likewise, the keyfile writer use g_object_get_property(). It also could do better.
2021-06-17 22:10:48 +02:00
/*****************************************************************************/
libnm-core: change how new and legacy properties are serialized Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
2014-11-14 11:46:19 -05:00
gboolean _nm_setting_use_legacy_property(NMSetting * setting,
GVariant * connection_dict,
const char *legacy_property,
const char *new_property);
libnm: hide API for generic handling of secrets The functions nm_setting_clear_secrets(), nm_setting_clear_secrets_with_flags(), and nm_setting_need_secrets() are not used outside of libnm-core. Remove them from public API. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-10-07 08:46:36 +02:00
GPtrArray *_nm_setting_need_secrets(NMSetting *setting);
libnm: rework compare_property() implementation for NMSetting NMSetting's compare_property() has and had two callers: nm_setting_compare() and nm_setting_diff(). compare_property() accepts a NMSettingCompareFlags argument, but at the same time, both callers have another complex (and inconsistent!) set of pre-checks for shortcuting the call of compare_property(): should_compare_prop(). Merge should_compare_prop() into compare_property(). This way, nm_setting_compare() and nm_setting_diff() has less additional code, and are simpler to follow. Especially nm_setting_compare() is now trivial. And nm_setting_diff() is still complicated, but not related to the question how the property compares or whether it should be compared at all. If you want to know whether it should be compared, all you need to do now is follow NMSettingClass.compare_property(). This changes function pointer NMSettingClass.compare_property(), which is public API. However, no user can actually use this (and shall not!), because _nm_setting_class_commit_full() etc. is private API. A user outside of libnm-core cannot create his/her own subclasses of NMSetting, and never could in the past. So, this API/ABI change doesn't matter.
2019-01-09 09:08:39 +01:00
gboolean _nm_setting_should_compare_secret_property(NMSetting * setting,
NMSetting * other,
const char * secret_name,
NMSettingCompareFlags flags);
libnm-core: add vlans property to bridge-port setting
2019-03-16 17:21:35 +01:00
NMBridgeVlan *_nm_bridge_vlan_dup(const NMBridgeVlan *vlan);
NMBridgeVlan *_nm_bridge_vlan_dup_and_seal(const NMBridgeVlan *vlan);
libnm: pass full property meta data to from_dbus_fcn() hook
2021-06-29 23:51:46 +02:00
gboolean _nm_utils_bridge_vlans_from_dbus(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMSetting * setting,
GVariant * connection_dict,
GVariant * value,
NMSettingParseFlags parse_flags,
GError ** error);
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
GVariant *_nm_utils_bridge_vlans_to_dbus(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty * property_info,
NMConnection * connection,
NMSetting * setting,
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
NMTernary _nm_setting_ip_config_compare_fcn_addresses(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMConnection * con_a,
NMSetting * set_a,
NMConnection * con_b,
NMSetting * set_b,
NMSettingCompareFlags flags);
NMTernary _nm_setting_ip_config_compare_fcn_routes(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMConnection * con_a,
NMSetting * set_a,
NMConnection * con_b,
NMSetting * set_b,
NMSettingCompareFlags flags);
gboolean _nm_utils_hwaddr_cloned_not_set(NMSetting * setting,
GVariant * connection_dict,
const char * property,
NMSettingParseFlags parse_flags,
GError ** error);
GVariant *_nm_utils_hwaddr_cloned_get(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty * property_info,
NMConnection * connection,
NMSetting * setting,
NMConnectionSerializationFlags flags,
const NMConnectionSerializationOptions *options);
libnm: pass full property meta data to from_dbus_fcn() hook
2021-06-29 23:51:46 +02:00
gboolean _nm_utils_hwaddr_cloned_set(const NMSettInfoSetting * sett_info,
const NMSettInfoProperty *property_info,
NMSetting * setting,
GVariant * connection_dict,
GVariant * value,
NMSettingParseFlags parse_flags,
GError ** error);
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
libnm: rework setting metadata for property handling NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
2018-07-28 15:26:03 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#endif /* NM_SETTING_PRIVATE_H */
Reference in a new issue Copy permalink