fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-20 16:20:05 +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.

1239 lines
84 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: move optimized NM_IS_{SIMPLE,}CONNECTION() to internal header We already redefine those checks to optimize for NMSimpleConnection. Which, in particular when libnm-core is used by the daemon, is the only implementation of the NMConnection interface. Move those to the private header file. No need to keep it private to "nm-connection.c".
2022-09-27 13:04:47 +02:00
#include "nm-simple-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: move NMValueStrv definition in header
2023-10-26 13:27:07 +02:00
/* This holds a property of type NM_VALUE_TYPE_STRV. You probably want
* to use nm_strvarray_*() API with this. */
typedef struct {
GArray *arr;
} NMValueStrv;
/*****************************************************************************/
libnm: use NMRefString for nm_connection_get_path() NMConnection is an interface, implemented by NMSimpleConnection and NMRemoteConnection. For the most part, an NMConnection is only the content of the profile (the settings). The "path" of the connection refers to the D-Bus path, and wouldn't really make sense of the NMConnection interface or the NMSimpleConnection type. As such, the daemon (which only uses NMConnection and NMSimpleConnection) never sets the path. Only libnm does. NMClient uses NMRefString extensively for the D-Bus interface and the path is already internalized. Take advantage of that. It is very likely, that we are able to share the path instance in libnm at which point it makes sense to use NMRefString. Also, during nm_simple_connection_new_clone(), we can just take another reference instead of cloning the string.
2022-09-26 13:39:23 +02:00
struct _NMRefString;
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 */
libnm: use NMRefString for nm_connection_get_path() NMConnection is an interface, implemented by NMSimpleConnection and NMRemoteConnection. For the most part, an NMConnection is only the content of the profile (the settings). The "path" of the connection refers to the D-Bus path, and wouldn't really make sense of the NMConnection interface or the NMSimpleConnection type. As such, the daemon (which only uses NMConnection and NMSimpleConnection) never sets the path. Only libnm does. NMClient uses NMRefString extensively for the D-Bus interface and the path is already internalized. Take advantage of that. It is very likely, that we are able to share the path instance in libnm at which point it makes sense to use NMRefString. Also, during nm_simple_connection_new_clone(), we can just take another reference instead of cloning the string.
2022-09-26 13:39:23 +02:00
struct _NMRefString *path;
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
} NMConnectionPrivate;
extern GTypeClass *_nm_simple_connection_class_instance;
extern int _nm_simple_connection_private_offset;
libnm: move optimized NM_IS_{SIMPLE,}CONNECTION() to internal header We already redefine those checks to optimize for NMSimpleConnection. Which, in particular when libnm-core is used by the daemon, is the only implementation of the NMConnection interface. Move those to the private header file. No need to keep it private to "nm-connection.c".
2022-09-27 13:04:47 +02:00
#undef NM_IS_SIMPLE_CONNECTION
#define NM_IS_SIMPLE_CONNECTION(self) \
({ \
gconstpointer _self1 = (self); \
gboolean _result; \
\
_result = \
(_self1 \
&& (((GTypeInstance *) _self1)->g_class == _nm_simple_connection_class_instance)); \
\
nm_assert(_result == G_TYPE_CHECK_INSTANCE_TYPE(_self1, NM_TYPE_SIMPLE_CONNECTION)); \
\
_result; \
})
#undef NM_IS_CONNECTION
#define NM_IS_CONNECTION(self) \
({ \
gconstpointer _self0 = (self); \
\
(_self0 \
&& (NM_IS_SIMPLE_CONNECTION(_self0) \
|| G_TYPE_CHECK_INSTANCE_TYPE(_self0, NM_TYPE_CONNECTION))); \
})
libnm: rework lookup of private data for NMConnection of NMSimpleConnection NMConnection is an interface, and as such has no data itself. In practice, there are only two implementations of this interface, NMSimpleConnection and NMRemoteConnection. The latter only exists in libnm, not the daemon. Thus, lookup of the private data is already optimized for NMSimpleConnection instances via _nm_simple_connection_private_offset. Use the same mechanism also for NMSimpleConnection itself.
2022-09-27 12:45:18 +02:00
#define _NM_SIMPLE_CONNECTION_GET_CONNECTION_PRIVATE(connection) \
({ \
gpointer _connection_1 = (connection); \
NMConnectionPrivate *_priv_1; \
\
nm_assert(NM_IS_SIMPLE_CONNECTION(_connection_1)); \
\
_priv_1 = (void *) (&(((char *) _connection_1)[_nm_simple_connection_private_offset])); \
\
nm_assert(_priv_1 \
== G_TYPE_INSTANCE_GET_PRIVATE(_connection_1, \
NM_TYPE_SIMPLE_CONNECTION, \
NMConnectionPrivate)); \
\
_priv_1; \
})
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
void _nm_connection_private_clear(NMConnectionPrivate *priv);
/*****************************************************************************/
libnm: embed private structure in NMSetting and avoid g_type_class_add_private() Historically, the NMSetting types were in public headers. Theoretically, that allowed users to subtype our classes. However in practice that was impossible because they lacked required access to internal functions to fully create an NMSetting class outside of libnm. And it also was not useful, because you simply cannot extend libnm by subtyping a libnm class. And supporting such a use case would be hard and limit what we can do in libnm. Having GObject structs in public headers also require that we don't change it's layout. The ABI of those structs must not change, if anybody out there was actually subclassing our GObjects. In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from public headers')) we moved the structs from headers to internal. This would have caused a compiler error if anybody was using those struct definitions. However, we still didn't change the ABI/layout so that we didn't break users who relied on it (for whatever reason). It doesn't seem there were any affected user. We waited long enough. Change internal ABI. No longer use g_type_class_add_private(). Instead, embed the private structs directly (_NM_GET_PRIVATE()) or indirectly (_NM_GET_PRIVATE_PTR()) in the object. The main benefit is for debugging in the debugger, where we can now easily find the private data. Previously that was so cumbersome to be effectively impossible. It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE() literally resolves to "&self->_priv" (plus static asserts and nm_assert() for type checking). _NM_GET_PRIVATE() also propagates constness and requires that the argument is a compatible pointer type (at compile time). Note that g_type_class_add_private() is also deprecated in glib 2.58 and replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also, G_ADD_PRIVATE() is a worse solution as it supports a usecase that we don't care for (public structs in headers). _NM_GET_PRIVATE() is still faster, works with older glib and most importantly: is better for debugging as you can find the private data from an object pointer. For NMSettingIPConfig this is rather awkward, because all direct properties require a common "klass->private_offset". This was however the case before this change. Nothing new here. And if you ever touch this and do something wrong, many unit tests will fail. It's almost impossible to get wrong, albeit it can be confusing to understand. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
struct _NMSettingPrivate;
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 {
libnm: embed private structure in NMSetting and avoid g_type_class_add_private() Historically, the NMSetting types were in public headers. Theoretically, that allowed users to subtype our classes. However in practice that was impossible because they lacked required access to internal functions to fully create an NMSetting class outside of libnm. And it also was not useful, because you simply cannot extend libnm by subtyping a libnm class. And supporting such a use case would be hard and limit what we can do in libnm. Having GObject structs in public headers also require that we don't change it's layout. The ABI of those structs must not change, if anybody out there was actually subclassing our GObjects. In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from public headers')) we moved the structs from headers to internal. This would have caused a compiler error if anybody was using those struct definitions. However, we still didn't change the ABI/layout so that we didn't break users who relied on it (for whatever reason). It doesn't seem there were any affected user. We waited long enough. Change internal ABI. No longer use g_type_class_add_private(). Instead, embed the private structs directly (_NM_GET_PRIVATE()) or indirectly (_NM_GET_PRIVATE_PTR()) in the object. The main benefit is for debugging in the debugger, where we can now easily find the private data. Previously that was so cumbersome to be effectively impossible. It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE() literally resolves to "&self->_priv" (plus static asserts and nm_assert() for type checking). _NM_GET_PRIVATE() also propagates constness and requires that the argument is a compatible pointer type (at compile time). Note that g_type_class_add_private() is also deprecated in glib 2.58 and replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also, G_ADD_PRIVATE() is a worse solution as it supports a usecase that we don't care for (public structs in headers). _NM_GET_PRIVATE() is still faster, works with older glib and most importantly: is better for debugging as you can find the private data from an object pointer. For NMSettingIPConfig this is rather awkward, because all direct properties require a common "klass->private_offset". This was however the case before this change. Nothing new here. And if you ever touch this and do something wrong, many unit tests will fail. It's almost impossible to get wrong, albeit it can be confusing to understand. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
GObject parent;
struct _NMSettingPrivate *_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
};
struct _NMSettingClass {
GObjectClass parent;
int (*verify)(NMSetting *setting, NMConnection *connection, GError **error);
gboolean (*verify_secrets)(NMSetting *setting, NMConnection *connection, GError **error);
core: move rerequest decision of secrets to NMSetting When an authentication attempt fails, NetworkManager re-requests new secrets from agents before retrying. This is currently decided outside of the NMSetting objects. With this change the decision if a re-request of new secrets is really needed is moved down to the NMSetting implementations. For the case "802.1x authentication with TLS" a certificate with password is configured and the assumption is, that this can never be wrong and no re-request is needed.
2022-10-07 10:59:02 +02:00
GPtrArray *(*need_secrets)(NMSetting *setting, gboolean check_rerequest);
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 (*update_one_secret)(NMSetting *setting, const char *key, GVariant *value, GError **error);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean (*get_secret_flags)(NMSetting *setting,
const char *secret_name,
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
NMSettingSecretFlags *out_flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean (*set_secret_flags)(NMSetting *setting,
const char *secret_name,
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
NMSettingSecretFlags flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error);
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
gboolean (*clear_secrets)(const struct _NMSettInfoSetting *sett_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMSettInfoProperty *property_info,
NMSetting *setting,
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
NMSettingClearSecretsWithFlagsFn func,
gpointer user_data);
void (*duplicate_copy_properties)(const struct _NMSettInfoSetting *sett_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSetting *src,
NMSetting *dst);
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 (*enumerate_values)(const struct _NMSettInfoProperty *property_info,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSetting *setting,
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
NMSettingValueIterFn func,
gpointer user_data);
gboolean (*aggregate)(NMSetting *setting, int type_i, gpointer arg);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
void (*for_each_secret)(NMSetting *setting,
const char *secret_name,
GVariant *val,
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
gboolean remove_non_secrets,
_NMConnectionForEachSecretFunc callback,
gpointer callback_data,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariantBuilder *setting_builder);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean (*init_from_dbus)(NMSetting *setting,
GHashTable *keys,
GVariant *setting_dict,
GVariant *connection_dict,
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
guint /* NMSettingParseFlags */ parse_flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error);
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;
};
struct _NMSettingIPConfigClass {
NMSettingClass parent;
libnm: embed private structure in NMSetting and avoid g_type_class_add_private() Historically, the NMSetting types were in public headers. Theoretically, that allowed users to subtype our classes. However in practice that was impossible because they lacked required access to internal functions to fully create an NMSetting class outside of libnm. And it also was not useful, because you simply cannot extend libnm by subtyping a libnm class. And supporting such a use case would be hard and limit what we can do in libnm. Having GObject structs in public headers also require that we don't change it's layout. The ABI of those structs must not change, if anybody out there was actually subclassing our GObjects. In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from public headers')) we moved the structs from headers to internal. This would have caused a compiler error if anybody was using those struct definitions. However, we still didn't change the ABI/layout so that we didn't break users who relied on it (for whatever reason). It doesn't seem there were any affected user. We waited long enough. Change internal ABI. No longer use g_type_class_add_private(). Instead, embed the private structs directly (_NM_GET_PRIVATE()) or indirectly (_NM_GET_PRIVATE_PTR()) in the object. The main benefit is for debugging in the debugger, where we can now easily find the private data. Previously that was so cumbersome to be effectively impossible. It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE() literally resolves to "&self->_priv" (plus static asserts and nm_assert() for type checking). _NM_GET_PRIVATE() also propagates constness and requires that the argument is a compatible pointer type (at compile time). Note that g_type_class_add_private() is also deprecated in glib 2.58 and replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also, G_ADD_PRIVATE() is a worse solution as it supports a usecase that we don't care for (public structs in headers). _NM_GET_PRIVATE() is still faster, works with older glib and most importantly: is better for debugging as you can find the private data from an object pointer. For NMSettingIPConfig this is rather awkward, because all direct properties require a common "klass->private_offset". This was however the case before this change. Nothing new here. And if you ever touch this and do something wrong, many unit tests will fail. It's almost impossible to get wrong, albeit it can be confusing to understand. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
int private_offset;
gint8 addr_family;
bool is_ipv4;
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 {
libnm: implement "ipv4.dhcp-reject-servers" as direct-strv property
2023-10-26 13:27:36 +02:00
NMValueStrv dns_search; /* array of domain name strings */
NMValueStrv dhcp_reject_servers;
libnm: implement "{ipv4,ipv6}.dns-options" as direct STRV property "nm_sett_info_propert_type_direct_strv" is the way, now STRV properties should be implemented. Adjust the "dns-options" property..
2023-11-15 20:16:18 +01:00
NMValueStrv dns_options; /* array of DNS options */
libnm: implement "ipv4.dns-search" as direct-strv property
2023-10-26 13:27:36 +02:00
GPtrArray *dns; /* array of IP address strings */
GPtrArray *addresses; /* array of NMIPAddress */
GPtrArray *routes; /* array of NMIPRoute */
GPtrArray *routing_rules;
char *method;
char *gateway;
char *dhcp_hostname;
char *dhcp_iaid;
libnm,nmcli: add ipvx.dhcp-dscp property Currently the internal DHCP client sets traffic class "CS6" in the DS field of the IP header for outgoing packets. dhclient sets the field according to the definition of TOS (RFC 1349), which was was deprecated in 1998 by RFC 2474 in favor of DSCP. Introduce a new property IPvX.dhcp-dscp (currently valid only for IPv4) to specify a custom DSCP value for DHCP backends that support it (currently, only the internal one). Define the default value to CS0, because: - section 4.9 of RFC 4594 specifies that DHCP should use the standard (CS0 = 0) service class; - section 3.2 says that class CS6 is for "transmitting packets between network devices (routers) that require control (routing) information to be exchanged between nodes", listing "OSPF, BGP, ISIS, RIP" as examples of such traffic. Furthermore, it says that: User traffic is not allowed to use this service class. By user traffic, we mean packet flows that originate from user-controlled end points that are connected to the network. - we got reports of some Cisco switches dropping DHCP packets because of the CS6 marking. (cherry picked from commit fcd907e062c72205ee2505ca6c175c6d1396f166)
2023-12-20 11:40:02 +01:00
char *dhcp_dscp;
libnm: implement "ipv4.dns-search" as direct-strv property
2023-10-26 13:27:36 +02:00
gint64 route_metric;
int auto_route_ext_gw;
int replace_local_rule;
ip: support dhcp-send-release in NMSettingIpConfig Introduce a new option to NMSettingIpConfig. The new option is ternary type being the default value set to disabled. When enabled, NetworkManager will instruct the DHCP client to send RELEASE message when IP addresses are being removed.
2024-01-26 14:04:51 +01:00
int dhcp_send_release;
libnm: implement "ipv4.dns-search" as direct-strv property
2023-10-26 13:27:36 +02:00
gint32 required_timeout;
gint32 dad_timeout;
gint32 dhcp_timeout;
gint32 dns_priority;
guint32 route_table;
guint32 dhcp_hostname_flags;
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: embed address family in NMSettingIPConfigClass for NM_SETTING_IP_CONFIG_GET_ADDR_FAMILY() The G_TYPE_INSTANCE_GET_CLASS() macro is just one pointer dereference (self)->g_class, plus additional assertions with debug builds. As such, it is as fast as it gets. Embed the address family there, and implement NM_SETTING_IP_CONFIG_GET_ADDR_FAMILY() that way. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1395
2022-09-26 21:50:42 +02:00
#define NM_SETTING_IP_CONFIG_GET_ADDR_FAMILY(setting) \
(NM_SETTING_IP_CONFIG_GET_CLASS(setting)->addr_family)
#define NM_SETTING_IP_CONFIG_IS_IPv4(setting) (NM_SETTING_IP_CONFIG_GET_CLASS(setting)->is_ipv4)
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
all: rename nmtst_* functions that are used by the daemon The name prefix "nmtst_*" is reserved for test helpers and stub function. Such functions should not be in the actual build artifacts, like the NetworkManager binary. Instead, nmtst_connection_assert_unchanging() is not a test helper. It is a assertion function that is only enabled with NM_MORE_ASSERTS builds. That's different. Rename. In other words, $ nm src/core/NetworkManager src/libnm-client-impl/.libs/libnm.so | grep nmtst should give no results.
2021-09-07 11:21:08 +02:00
int _nm_setting_sort_for_nm_assert(NMSetting *a, NMSetting *b);
libnm: add nm_meta_setting_info helpers
2021-06-11 15:28:42 +02:00
/*****************************************************************************/
#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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean _nm_setting_clear_secrets(NMSetting *setting,
libnm: merge _nm_setting_clear_secrets() and *_with_flags()
2019-01-13 20:47:05 +01:00
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
/*****************************************************************************/
libnm: add direct strv type for NMSetting and use it for "match.interface-name" G_TYPE_STRV is the last property type in NMSetting that is implemented by directly accessing the GObect property. Note that we have lots of override, non-default implementations that still use GObject properties, but I am talking here about properties that don't have a special implementation and use a G_TYPE_STRV GObject property. Add a "direct" implementation also for strv arrays. The advantage is that we no longer call g_value_get() for various operations, which requires a deep-copy of the strv array. The other advantage is that we will get a unified approach for implementing strv properties. In particular strv arrays need a lot of code to implement, and most settings do it differently. By adding a general mechanism, this code (and behavior) can be unified. Showcase it on "match.interface-name".
2022-01-24 17:10:34 +01:00
libnm: add NMRange The next commit is going to introduce a new object in libnm to represent a range of ovs-port VLANs. A "range of integers" object seems something that can be used for other purposes in the future, so instead of adding an object specific for this case (e.g. NMOvsPortVlanRange), introduce a generic NMRange object that generically represents a range of non-negative integers.
2022-11-18 17:07:23 +01:00
struct _NMRange {
libnm: make ref counting of immutable types thread safe The types NMBridgeVlan, NMIPRoutingRule, NMRange, NMWireGuardPeer are immutable (or immutable, after the seal() function is called). Immutable types are great, as it means a reference to them can be shared without doing a full clone. Hence the G_DEFINE_BOXED_TYPE() for these types prefers to take a reference instead of cloning the objects. Except for sealable types, where it will prefer to clone unsealed values. Likewise, nm_simple_connection_new_clone() probably will just take another reference to the value, instead of doing a deep clone. libnm is not a thread-safe library in the sense that you could pass a NMConnection or NMClient instance to multiple threads and access them without your own synchronization. However, it should be possible that multiple threads access (seemingly) distinct objects. As the copy function of these boxed types (and nm_simple_connection_new_clone() and similar) prefers to share the references to immutable types, it is important that the ref function is thread-safe too. Otherwise you cannot just clone a NMConnection on thread1, hand the clone to thread2 and operate on the clone and the original independently. If you do before this patch, you would hit a subtle race condition. Avoid that. While atomic operations have a runtime overhead, being safe is more important. Also, we already save a full malloc()/free() by having immutable, ref-counted types. We just need to make it safe to use in order to fully benefit from it.
2022-11-30 16:55:09 +01:00
int refcount;
libnm: add NMRange The next commit is going to introduce a new object in libnm to represent a range of ovs-port VLANs. A "range of integers" object seems something that can be used for other purposes in the future, so instead of adding an object specific for this case (e.g. NMOvsPortVlanRange), introduce a generic NMRange object that generically represents a range of non-negative integers.
2022-11-18 17:07:23 +01:00
guint64 start;
guint64 end;
};
/*****************************************************************************/
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
trivial: fix typos
2021-12-29 14:29:09 -03:00
* this flag, are ignored when doing an inferrable comparison. This flag should
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
* 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: refactor to-dbus on the client skipping to serialize legacy properties We have 4 legacy properties ("ipv[46].addresses", "ipv[46].routes") that got replaced by newer variants ("ipv[46].address-data", "ipv[46].route-data"). When the client side of libnm (_nm_utils_is_manager_process) serializes those properties, it must only serialize the newer version. That is so that the forward/backward compatibility works as intended. Previously, there was the NM_SETTING_PARAM_LEGACY GObject property flag. That was fine, but not very clear. For one, the legacy part of those properties is only about D-Bus. In particular, they are not deprecated in libnm, keyfile, or nmcli. Thus the name wasn't very clear. Also, in the meantime we have more elaborate property meta data, that goes beyond the meta data of the GObject property. Move NM_SETTING_PARAM_LEGACY to NMSettInfoProperty.to_dbus_only_in_manager_process. I think, this is a better name. It's also right at ``` _nm_properties_override_gobj( properties_override, g_object_class_find_property(G_OBJECT_CLASS(setting_class), NM_SETTING_IP_CONFIG_ROUTES), NM_SETT_INFO_PROPERT_TYPE_DBUS(NM_G_VARIANT_TYPE("a(ayuayu)"), .to_dbus_fcn = ip6_routes_to_dbus, .compare_fcn = _nm_setting_ip_config_compare_fcn_routes, .from_dbus_fcn = ip6_routes_from_dbus, ), .to_dbus_only_in_manager_process = TRUE, .dbus_deprecated = TRUE, ); ``` that is, directly at the place where we describe how the D-Bus property behaves.
2022-10-24 13:22:40 +02:00
/* This flag has no meaning (anymore). It's only kept, because we used it
* on some older versions of libnm. */
#define NM_SETTING_PARAM_UNUSED1 (1 << (5 + 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
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;
libnm: reuse static property type for strv properties
2023-10-25 11:58:29 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_gprop_strv_oldstyle;
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: 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 nm_sett_info_propert_type_direct_int32 property type
2021-07-13 22:56:05 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_int32;
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 property type "int64"
2022-01-05 15:29:50 +01:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_int64;
libnm: add direct property type "uint64"
2021-10-20 10:53:39 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_uint64;
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 property type "bytes"
2021-10-27 20:24:17 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_bytes;
libnm: add direct strv type for NMSetting and use it for "match.interface-name" G_TYPE_STRV is the last property type in NMSetting that is implemented by directly accessing the GObect property. Note that we have lots of override, non-default implementations that still use GObject properties, but I am talking here about properties that don't have a special implementation and use a G_TYPE_STRV GObject property. Add a "direct" implementation also for strv arrays. The advantage is that we no longer call g_value_get() for various operations, which requires a deep-copy of the strv array. The other advantage is that we will get a unified approach for implementing strv properties. In particular strv arrays need a lot of code to implement, and most settings do it differently. By adding a general mechanism, this code (and behavior) can be unified. Showcase it on "match.interface-name".
2022-01-24 17:10:34 +01:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_strv;
libnm: add direct property type "enum"
2021-10-20 10:53:39 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_enum;
libnm: add direct property type "flags" "flags" are a g_param_spec_flags() and correspond to G_TYPE_FLAGS type. They are internally stored as guint, and exported on D-Bus as "u" (32 bit integer).
2021-10-20 10:53:39 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_flags;
libnm: add nm_sett_info_propert_type_direct_mac_address A MAC address is a relatively common "type". The GObject property is of type string, but the D-Bus type is a bytestring ("ay"). We will need a special NMSettInfoPropertType. Note that like most implementations, the from-dbus implementation still is based on GObject setters. This will change in the future. Also note that the previous compare function was _nm_setting_property_compare_fcn_default(). That is, it used to convert the property to GVariant and compare those. The conversion to GVariant in that case normalizes the string (e.g. it is case insensitive). Also, only properties could be compared which were also convertible to D-Bus (which is probably fine, because there is no guarantee the profiles that don't verify can be compared). The code now uses the direct comparison of the strings. That mostly preserves the case-insensitivity of the previous comparison, because the property setters for mac addresses all use _nm_utils_hwaddr_canonical_or_invalid() to normalize the strings. This is subtle, but still correct. Note that this will improve later, by ensuring that the property setters for mac addresses automatically perform the right normalization.
2021-07-13 18:09:13 +02:00
extern const NMSettInfoPropertType nm_sett_info_propert_type_direct_mac_address;
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean _nm_setting_compare_flags_check(const GParamSpec *param_spec,
libnm: add _nm_setting_compare_flags_check() helper
2021-06-29 18:12:56 +02:00
NMSettingCompareFlags flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSetting *set_a,
NMSetting *set_b);
libnm: add _nm_setting_compare_flags_check() helper
2021-06-29 18:12:56 +02:00
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
NMTernary _nm_setting_property_compare_fcn_ignore(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
NMTernary _nm_setting_property_compare_fcn_direct(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
NMTernary _nm_setting_property_compare_fcn_default(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
void _nm_setting_property_get_property_direct(GObject *object,
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
guint prop_id,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GValue *value,
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
GParamSpec *pspec);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
void _nm_setting_property_set_property_direct(GObject *object,
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
guint prop_id,
const GValue *value,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GParamSpec *pspec);
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
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
GVariant *_nm_setting_property_to_dbus_fcn_ignore(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_property_to_dbus_fcn_gprop(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_property_to_dbus_fcn_direct(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
GVariant *
_nm_setting_property_to_dbus_fcn_direct_mac_address(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_property_from_dbus_fcn_ignore(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_property_from_dbus_fcn_direct_ip_config_gateway(
_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_property_from_dbus_fcn_direct_mac_address(
_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_property_from_dbus_fcn_direct(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_property_from_dbus_fcn_gprop(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
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
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
gboolean _nm_setting_connection_controller_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_connection_controller_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_connection_master_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
gboolean _nm_setting_connection_port_type_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_connection_port_type_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_connection_slave_type_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
connection: deprecate NMSettingConnection autoconnect-slaves property To embrace inclusive language, deprecate the NMSettingConnection autoconnect-slaves property and introduce autoconnect-ports property. (cherry picked from commit 194455660d15bfa6bb9fb291205edda17c519f93)
2024-01-22 14:58:56 +01:00
gboolean
_nm_setting_connection_autoconnect_ports_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *
_nm_setting_connection_autoconnect_ports_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean
_nm_setting_connection_autoconnect_slaves_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
wireless: deprecate NMSettingWireless mac-address-blacklist property To embrace inclusive language, deprecate the NMSettingWireless mac-address-blacklist property and introduce mac-address-denylist property.
2024-02-19 14:51:36 +01:00
gboolean _nm_setting_wireless_mac_denylist_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_wireless_mac_denylist_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean
_nm_setting_wireless_mac_blacklist_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
wired: deprecate NMSettingWired mac-address-blacklist property To embrace inclusive language, deprecate the NMSettingWired mac-address-blacklist property and introduce mac-address-denylist property.
2024-03-13 12:44:59 +01:00
gboolean _nm_setting_wired_mac_denylist_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_setting_wired_mac_denylist_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
gboolean _nm_setting_wired_mac_blacklist_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariant *_nm_setting_to_dbus(NMSetting *setting,
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error);
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
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);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean _nm_setting_property_is_regular_secret_flags(NMSetting *setting,
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
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const GParamSpec *param_spec);
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
libnm: rework creating property info for "name" The goal is to have the properties_overrides already pre-populated with all properties. Then we will be able to drop special cases from _nm_setting_class_commit().
2023-10-25 11:26:13 +02:00
GArray *_nm_sett_info_property_override_create_array_sized(guint reserved_size);
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
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
}
libnm: implement special setter for direct string property for ip address This is a normalization employed by NMSettingIPConfig.gateway. Also rework NMSettingIPConfig.set_property() to no longer assert against valid input. We want to pass there untrusted strings from D-Bus, asserting is a horrible idea. Instead, either normalize the string or keep the invalid text that will be rejected by verify().
2021-07-14 07:40:35 +02:00
GArray *_nm_sett_info_property_override_create_array_ip_config(int addr_family);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
void _nm_setting_class_commit(NMSettingClass *setting_class,
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
NMMetaSettingType meta_type,
const NMSettInfoSettDetail *detail,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GArray *properties_override,
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
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: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01:00
static inline guint
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: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01:00
return properties_override->len - 1u;
libnm: cleanup _properties_override_add*() functions
2019-09-22 15:23:41 +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: initialize "name" in _nm_properties_override_gobj() Previously, _nm_setting_class_commit() required that the "name" of a NMSettInfoProperty is unset, when the property also has a "param_spec". _nm_setting_class_commit() would then as first iterate over all properties, and set the name. In practice, all callers only initialize NMSettInfoProperty via _nm_properties_override_gobj(). Now, let _nm_properties_override_gobj() set the "name" right away. Now _nm_setting_class_commit() will instead assert that the name is always set, and that the caller takes care of that. That means, we have less to do in _nm_setting_class_commit() (assertions aside).
2023-10-25 17:25:26 +02:00
#define _nm_properties_override_gobj(properties_override, \
p_param_spec, \
p_property_type, \
... /* extra NMSettInfoProperty fields */) \
libnm: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01:00
({ \
libnm: initialize "name" in _nm_properties_override_gobj() Previously, _nm_setting_class_commit() required that the "name" of a NMSettInfoProperty is unset, when the property also has a "param_spec". _nm_setting_class_commit() would then as first iterate over all properties, and set the name. In practice, all callers only initialize NMSettInfoProperty via _nm_properties_override_gobj(). Now, let _nm_properties_override_gobj() set the "name" right away. Now _nm_setting_class_commit() will instead assert that the name is always set, and that the caller takes care of that. That means, we have less to do in _nm_setting_class_commit() (assertions aside).
2023-10-25 17:25:26 +02:00
GParamSpec *const _p_param_spec_2 = (p_param_spec); \
\
nm_assert(_p_param_spec_2); \
\
_nm_properties_override((properties_override), \
NM_SETT_INFO_PROPERTY(.name = _p_param_spec_2->name, \
.param_spec = _p_param_spec_2, \
.property_type = (p_property_type), \
__VA_ARGS__)); \
libnm: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01: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
libnm: add extra arguments to _nm_properties_override_dbus()
2022-10-24 11:16:42 +02:00
#define _nm_properties_override_dbus(properties_override, \
p_name, \
p_property_type, \
... /* extra NMSettInfoProperty fields */) \
_nm_properties_override((properties_override), \
NM_SETT_INFO_PROPERTY(.name = ("" p_name ""), \
.property_type = (p_property_type), \
__VA_ARGS__))
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); \
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GParamSpec *_param_spec; \
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
\
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)); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct boolean properties Now that we require glib 2.42, we can use G_PARAM_EXPLICIT_NOTIFY flag. The benefit is that this flag saves a notification, when the property value does not change. The downside is, that implementations of set_property() must remember to emit _notify() when required. This is somewhat alleviated by using _nm_setting_property_set_property_direct(), which does this automatically. Se the flag for G_PARAM_EXPLICIT_NOTIFY for direct boolean properties. For now, only do it for boolean properties, because of the danger of getting this wrong. We must review all callers to make sure that they don't implement set_properties() and don't forget to notify.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_boolean("" prop_name "", \
"", \
"", \
_default_value, \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
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
\
(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))); \
libnm: add nm_sett_info_propert_type_direct_int32 property type
2021-07-13 22:56:05 +02:00
G_STATIC_ASSERT((min_value) <= (guint64) (default_value)); \
G_STATIC_ASSERT((default_value) <= (guint64) (max_value)); \
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
G_STATIC_ASSERT((max_value) <= (guint64) G_MAXUINT32); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct uint32 properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_uint("" prop_name "", \
"", \
"", \
(min_value), \
(max_value), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
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
\
(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 nm_sett_info_propert_type_direct_int32 property type
2021-07-13 22:56:05 +02:00
#define _nm_setting_property_define_direct_int32(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) >= (gint64) (G_MININT32)); \
G_STATIC_ASSERT((min_value) <= (gint64) (default_value)); \
G_STATIC_ASSERT((default_value) <= (gint64) (max_value)); \
G_STATIC_ASSERT((max_value) <= (gint64) G_MAXUINT32); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct int32 properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_int("" prop_name "", \
"", \
"", \
(min_value), \
(max_value), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add nm_sett_info_propert_type_direct_int32 property type
2021-07-13 22:56:05 +02:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_int32, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(gint32, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
libnm: add direct property type "uint64"
2021-10-20 10:53:39 +02:00
G_STMT_END
/*****************************************************************************/
libnm: add direct property type "int64"
2022-01-05 15:29:50 +01:00
#define _nm_setting_property_define_direct_int64(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) >= G_MININT64); \
G_STATIC_ASSERT((min_value) <= (default_value)); \
G_STATIC_ASSERT((default_value) <= (max_value)); \
G_STATIC_ASSERT((max_value) <= G_MAXINT64); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct int64,uint64 properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_int64("" prop_name "", \
"", \
"", \
(min_value), \
(max_value), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add direct property type "int64"
2022-01-05 15:29:50 +01:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_int64, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(gint64, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
/*****************************************************************************/
libnm: add direct property type "uint64"
2021-10-20 10:53:39 +02:00
#define _nm_setting_property_define_direct_uint64(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) <= (default_value)); \
Updated code format The CI will use Fedora 40 for code formatting check. Update the code formatting so it passes.
2024-04-05 08:20:02 +02:00
G_STATIC_ASSERT((default_value) == 0 || (default_value) - 1u < (max_value)); \
libnm: add direct property type "uint64"
2021-10-20 10:53:39 +02:00
G_STATIC_ASSERT((max_value) <= G_MAXUINT64); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct int64,uint64 properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_uint64("" prop_name "", \
"", \
"", \
(min_value), \
(max_value), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add direct property type "uint64"
2021-10-20 10:53:39 +02:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_uint64, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(guint64, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
libnm: add nm_sett_info_propert_type_direct_int32 property type
2021-07-13 22:56:05 +02:00
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 */) \
libnm: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01:00
({ \
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GParamSpec *_param_spec; \
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
const NMSettInfoPropertType *_property_type = (property_type); \
\
G_STATIC_ASSERT(!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_SECRET | NM_SETTING_PARAM_FUZZY_IGNORE \
libnm: refactor some NMSetting to use direct properties for string
2021-12-28 10:50:05 +01:00
| NM_SETTING_PARAM_INFERRABLE | NM_SETTING_PARAM_REQUIRED \
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
| 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); \
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
nm_assert(NM_IN_SET(_property_type->to_dbus_fcn, \
_nm_setting_property_to_dbus_fcn_direct, \
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
_nm_setting_connection_controller_to_dbus, \
_nm_setting_connection_port_type_to_dbus)); \
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
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct string properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_string("" prop_name "", \
"", \
"", \
NULL, \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
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
\
(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: return property index from _nm_setting_property_define_direct_string() We will need this, when we incrementally construct the list of properties.
2023-12-11 11:59:25 +01:00
})
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
#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: add direct property type "flags" "flags" are a g_param_spec_flags() and correspond to G_TYPE_FLAGS type. They are internally stored as guint, and exported on D-Bus as "u" (32 bit integer).
2021-10-20 10:53:39 +02:00
libnm: add direct property type "bytes"
2021-10-27 20:24:17 +02:00
#define _nm_setting_property_define_direct_bytes(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
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_SECRET | NM_SETTING_PARAM_INFERRABLE \
| NM_SETTING_PARAM_FUZZY_IGNORE))); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct bytes properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_boxed("" prop_name "", \
"", \
"", \
G_TYPE_BYTES, \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add direct property type "bytes"
2021-10-27 20:24:17 +02:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_bytes, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(GBytes *, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
/*****************************************************************************/
libnm: add property_type argument to _nm_setting_property_define_direct_strv The purpose of this is to allow overriding to_dbus_fcn and from_dbus_fcn when necessary (such as for special behavior regarding a deprecated/aliased properties).
2024-02-19 14:39:25 +01:00
#define _nm_setting_property_define_direct_strv(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
param_flags, \
property_type, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
({ \
GParamSpec *_param_spec; \
const NMSettInfoPropertType *_property_type; \
G_STATIC_ASSERT(!NM_FLAGS_ANY((param_flags), ~(NM_SETTING_PARAM_FUZZY_IGNORE))); \
\
_param_spec = g_param_spec_boxed("" prop_name "", \
"", \
"", \
G_TYPE_STRV, \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
_property_type = (property_type) ?: &nm_sett_info_propert_type_direct_strv; \
\
_nm_properties_override_gobj((properties_override), \
_param_spec, \
_property_type, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(NMValueStrv, \
private_struct_type, \
private_struct_field), \
__VA_ARGS__); \
libnm: allow _nm_setting_property_define_direct_strv() to be used as expression This is so that the resulting index can be used for aliasing properties.
2024-02-15 13:51:40 +01:00
})
libnm: add direct strv type for NMSetting and use it for "match.interface-name" G_TYPE_STRV is the last property type in NMSetting that is implemented by directly accessing the GObect property. Note that we have lots of override, non-default implementations that still use GObject properties, but I am talking here about properties that don't have a special implementation and use a G_TYPE_STRV GObject property. Add a "direct" implementation also for strv arrays. The advantage is that we no longer call g_value_get() for various operations, which requires a deep-copy of the strv array. The other advantage is that we will get a unified approach for implementing strv properties. In particular strv arrays need a lot of code to implement, and most settings do it differently. By adding a general mechanism, this code (and behavior) can be unified. Showcase it on "match.interface-name".
2022-01-24 17:10:34 +01:00
/*****************************************************************************/
nm-setting: implement direct_enum as GObject property of type int (cherry picked from commit 260865b1acbe8d7b22a47bcc1e23982b07c20d15)
2024-02-20 14:50:15 +00:00
/* Define a direct property of type enum, but using `int` as type in the underlying
* GObject property. This is the preferred way to define enum properties because using
* real enums it is not possible to maintain backwards compatibility with clients
* using an old libnm (glib asserts against new values of the enum not being valid).
* The main difference from define_direct_real_enum is that this will accept any
* integer value, and we'll check that it's valid in #NMSetting::verify, as doing
* 'verify' is optional for clients. */
connection: deprecate NMSettingConnection autoconnect-slaves property To embrace inclusive language, deprecate the NMSettingConnection autoconnect-slaves property and introduce autoconnect-ports property. (cherry picked from commit 194455660d15bfa6bb9fb291205edda17c519f93)
2024-01-22 14:58:56 +01:00
#define _nm_setting_property_define_direct_enum(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
gtype_enum, \
default_value, \
param_flags, \
property_type, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
({ \
GParamSpec *_param_spec; \
const NMSettInfoPropertType *_property_type; \
\
G_STATIC_ASSERT( \
!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_REAPPLY_IMMEDIATELY | NM_SETTING_PARAM_FUZZY_IGNORE \
| NM_SETTING_PARAM_INFERRABLE))); \
\
nm-setting: implement direct_enum as GObject property of type int (cherry picked from commit 260865b1acbe8d7b22a47bcc1e23982b07c20d15)
2024-02-20 14:50:15 +00:00
nm_assert(G_TYPE_IS_ENUM(gtype_enum)); \
\
_param_spec = g_param_spec_int("" prop_name "", \
"", \
"", \
G_MININT32, \
G_MAXINT32, \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
_property_type = (property_type) ?: &nm_sett_info_propert_type_direct_enum; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
_property_type, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(int, private_struct_type, private_struct_field), \
.direct_data.enum_gtype = (gtype_enum), \
__VA_ARGS__); \
})
/*****************************************************************************/
/* Define an enum property using real enums in the GObject, not integers. Note that
* this is not backwards compatible because clients with old libnm will reject
* newer values of the enum. Generally you want to use define_direct_enum and use this
* one only for properties that already existed as real enums */
#define _nm_setting_property_define_direct_real_enum(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
gtype_enum, \
default_value, \
param_flags, \
property_type, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
({ \
GParamSpec *_param_spec; \
const NMSettInfoPropertType *_property_type; \
\
G_STATIC_ASSERT( \
!NM_FLAGS_ANY((param_flags), \
~(NM_SETTING_PARAM_REAPPLY_IMMEDIATELY | NM_SETTING_PARAM_FUZZY_IGNORE \
| NM_SETTING_PARAM_INFERRABLE))); \
\
nm_assert(G_TYPE_IS_ENUM(gtype_enum)); \
\
connection: deprecate NMSettingConnection autoconnect-slaves property To embrace inclusive language, deprecate the NMSettingConnection autoconnect-slaves property and introduce autoconnect-ports property. (cherry picked from commit 194455660d15bfa6bb9fb291205edda17c519f93)
2024-01-22 14:58:56 +01:00
_param_spec = g_param_spec_enum("" prop_name "", \
"", \
"", \
(gtype_enum), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
\
(obj_properties)[(prop_id)] = _param_spec; \
_property_type = (property_type) ?: &nm_sett_info_propert_type_direct_enum; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
_property_type, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(int, private_struct_type, private_struct_field), \
nm-setting: implement direct_enum as GObject property of type int (cherry picked from commit 260865b1acbe8d7b22a47bcc1e23982b07c20d15)
2024-02-20 14:50:15 +00:00
.direct_data.enum_gtype = (gtype_enum), \
connection: deprecate NMSettingConnection autoconnect-slaves property To embrace inclusive language, deprecate the NMSettingConnection autoconnect-slaves property and introduce autoconnect-ports property. (cherry picked from commit 194455660d15bfa6bb9fb291205edda17c519f93)
2024-01-22 14:58:56 +01:00
__VA_ARGS__); \
setting: add property_type field to _nm_setting_property_define_direct_enum In order to make _nm_setting_property_define_direct_enum more flexible, this patch is introducing property_type argument to it. When set to NULL it will set property_type to nm_sett_info_propert_type_direct_enum. (cherry picked from commit b90dd247be3c1088a92c81cd74bf0977d1f99be4)
2024-01-22 14:50:13 +01:00
})
libnm: add direct property type "enum"
2021-10-20 10:53:39 +02:00
/*****************************************************************************/
nm-setting: implement direct_enum as GObject property of type int (cherry picked from commit 260865b1acbe8d7b22a47bcc1e23982b07c20d15)
2024-02-20 14:50:15 +00:00
#define _nm_setting_property_is_valid_direct_enum(property_info) \
({ \
const NMSettInfoProperty *_property_info = (property_info); \
NMValueType direct_nmtype = _property_info->property_type->direct_type; \
GType direct_gtype = _property_info->direct_data.enum_gtype; \
GParamSpec *spec = _property_info->param_spec; \
GType spec_gtype = spec ? spec->value_type : G_TYPE_INVALID; \
\
direct_nmtype == NM_VALUE_TYPE_ENUM &&direct_gtype &&G_TYPE_IS_ENUM(direct_gtype) \
&& NM_IN_SET(spec_gtype, G_TYPE_INT, direct_gtype); \
})
/*****************************************************************************/
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
#define _nm_setting_property_define_direct_ternary_enum(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
param_flags, \
private_struct_type, \
private_struct_field, \
...) \
nm-setting: implement direct_enum as GObject property of type int (cherry picked from commit 260865b1acbe8d7b22a47bcc1e23982b07c20d15)
2024-02-20 14:50:15 +00:00
_nm_setting_property_define_direct_real_enum((properties_override), \
(obj_properties), \
prop_name, \
(prop_id), \
NM_TYPE_TERNARY, \
NM_TERNARY_DEFAULT, \
(param_flags), \
NULL, \
private_struct_type, \
private_struct_field, \
__VA_ARGS__)
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
/*****************************************************************************/
libnm: add direct property type "flags" "flags" are a g_param_spec_flags() and correspond to G_TYPE_FLAGS type. They are internally stored as guint, and exported on D-Bus as "u" (32 bit integer).
2021-10-20 10:53:39 +02:00
#define _nm_setting_property_define_direct_flags(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
gtype_flags, \
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))); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct flags properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_flags("" prop_name "", \
"", \
"", \
(gtype_flags), \
(default_value), \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add direct property type "flags" "flags" are a g_param_spec_flags() and correspond to G_TYPE_FLAGS type. They are internally stored as guint, and exported on D-Bus as "u" (32 bit integer).
2021-10-20 10:53:39 +02:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_flags, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(guint, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
/*****************************************************************************/
#define _nm_setting_property_define_direct_secret_flags(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
private_struct_type, \
private_struct_field, \
... /* extra NMSettInfoProperty fields */) \
_nm_setting_property_define_direct_flags((properties_override), \
(obj_properties), \
prop_name, \
(prop_id), \
NM_TYPE_SETTING_SECRET_FLAGS, \
NM_SETTING_SECRET_FLAG_NONE, \
NM_SETTING_PARAM_NONE, \
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: add nm_sett_info_propert_type_direct_mac_address A MAC address is a relatively common "type". The GObject property is of type string, but the D-Bus type is a bytestring ("ay"). We will need a special NMSettInfoPropertType. Note that like most implementations, the from-dbus implementation still is based on GObject setters. This will change in the future. Also note that the previous compare function was _nm_setting_property_compare_fcn_default(). That is, it used to convert the property to GVariant and compare those. The conversion to GVariant in that case normalizes the string (e.g. it is case insensitive). Also, only properties could be compared which were also convertible to D-Bus (which is probably fine, because there is no guarantee the profiles that don't verify can be compared). The code now uses the direct comparison of the strings. That mostly preserves the case-insensitivity of the previous comparison, because the property setters for mac addresses all use _nm_utils_hwaddr_canonical_or_invalid() to normalize the strings. This is subtle, but still correct. Note that this will improve later, by ensuring that the property setters for mac addresses automatically perform the right normalization.
2021-07-13 18:09:13 +02:00
#define _nm_setting_property_define_direct_mac_address(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
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_SECRET | NM_SETTING_PARAM_FUZZY_IGNORE \
| NM_SETTING_PARAM_INFERRABLE \
| NM_SETTING_PARAM_REAPPLY_IMMEDIATELY))); \
\
libnm: use G_PARAM_EXPLICIT_NOTIFY for direct string properties For doing this, it's important to review that no set_property() implementation exists, which now would miss to emit the notification.
2023-12-11 12:09:13 +01:00
_param_spec = g_param_spec_string("" prop_name "", \
"", \
"", \
NULL, \
G_PARAM_READWRITE | G_PARAM_EXPLICIT_NOTIFY \
| G_PARAM_STATIC_STRINGS | (param_flags)); \
libnm: add nm_sett_info_propert_type_direct_mac_address A MAC address is a relatively common "type". The GObject property is of type string, but the D-Bus type is a bytestring ("ay"). We will need a special NMSettInfoPropertType. Note that like most implementations, the from-dbus implementation still is based on GObject setters. This will change in the future. Also note that the previous compare function was _nm_setting_property_compare_fcn_default(). That is, it used to convert the property to GVariant and compare those. The conversion to GVariant in that case normalizes the string (e.g. it is case insensitive). Also, only properties could be compared which were also convertible to D-Bus (which is probably fine, because there is no guarantee the profiles that don't verify can be compared). The code now uses the direct comparison of the strings. That mostly preserves the case-insensitivity of the previous comparison, because the property setters for mac addresses all use _nm_utils_hwaddr_canonical_or_invalid() to normalize the strings. This is subtle, but still correct. Note that this will improve later, by ensuring that the property setters for mac addresses automatically perform the right normalization.
2021-07-13 18:09:13 +02:00
\
(obj_properties)[(prop_id)] = _param_spec; \
\
_nm_properties_override_gobj( \
(properties_override), \
_param_spec, \
&nm_sett_info_propert_type_direct_mac_address, \
.direct_offset = \
NM_STRUCT_OFFSET_ENSURE_TYPE(char *, private_struct_type, private_struct_field), \
__VA_ARGS__); \
} \
G_STMT_END
libnm: add _nm_setting_property_define_gprop_strv_oldstyle() define This will be used for adding G_TYPE_STRV properties. This is a legacy approach, new properties should use _nm_setting_property_define_direct_strv(), which is more efficient and where the meta-data knows more about the strv property. Will be used next.
2023-10-25 13:15:58 +02:00
/* This should not be used for new strv properties. Use _nm_setting_property_define_direct_strv().
*
* FIXME: existing properties should migrate to _nm_setting_property_define_direct_strv(). */
#define _nm_setting_property_define_gprop_strv_oldstyle(properties_override, \
obj_properties, \
prop_name, \
prop_id, \
param_flags) \
G_STMT_START \
{ \
GParamSpec *_param_spec; \
\
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))); \
\
_param_spec = \
g_param_spec_boxed("" prop_name "", \
"", \
"", \
G_TYPE_STRV, \
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_gprop_strv_oldstyle); \
} \
G_STMT_END
libnm: add nm_sett_info_propert_type_direct_mac_address A MAC address is a relatively common "type". The GObject property is of type string, but the D-Bus type is a bytestring ("ay"). We will need a special NMSettInfoPropertType. Note that like most implementations, the from-dbus implementation still is based on GObject setters. This will change in the future. Also note that the previous compare function was _nm_setting_property_compare_fcn_default(). That is, it used to convert the property to GVariant and compare those. The conversion to GVariant in that case normalizes the string (e.g. it is case insensitive). Also, only properties could be compared which were also convertible to D-Bus (which is probably fine, because there is no guarantee the profiles that don't verify can be compared). The code now uses the direct comparison of the strings. That mostly preserves the case-insensitivity of the previous comparison, because the property setters for mac addresses all use _nm_utils_hwaddr_canonical_or_invalid() to normalize the strings. This is subtle, but still correct. Note that this will improve later, by ensuring that the property setters for mac addresses automatically perform the right normalization.
2021-07-13 18:09:13 +02:00
/*****************************************************************************/
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean _nm_setting_use_legacy_property(NMSetting *setting,
GVariant *connection_dict,
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
const char *legacy_property,
const char *new_property);
core: move rerequest decision of secrets to NMSetting When an authentication attempt fails, NetworkManager re-requests new secrets from agents before retrying. This is currently decided outside of the NMSetting objects. With this change the decision if a re-request of new secrets is really needed is moved down to the NMSetting implementations. For the case "802.1x authentication with TLS" a certificate with password is configured and the assumption is, that this can never be wrong and no re-request is needed.
2022-10-07 10:59:02 +02:00
GPtrArray *_nm_setting_need_secrets(NMSetting *setting, gboolean check_rerequest);
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
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gboolean _nm_setting_should_compare_secret_property(NMSetting *setting,
NMSetting *other,
const char *secret_name,
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
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: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
gboolean _nm_utils_bridge_vlans_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
GVariant *_nm_utils_bridge_vlans_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
libnm: add ovs-port.trunks property Add a new "ovs-port.trunks" property that indicates which VLANs are trunked by the port. At ovsdb level the property is just an array of integers; on the command line, ovs-vsctl accepts ranges and expands them. In NetworkManager the ovs-port setting stores the trunks directly as a list of ranges.
2022-11-18 17:43:57 +01:00
gboolean _nm_utils_ranges_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
NMTernary _nm_utils_ranges_cmp(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
GVariant *_nm_utils_ranges_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
NMTernary _nm_setting_ip_config_compare_fcn_addresses(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
NMTernary _nm_setting_ip_config_compare_fcn_routes(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
libnm: fix comparing "ipv[46].dns" properties nm_setting_diff() ends up calling the compare_fcn() hook. Previously, the hook for "dns" was _nm_setting_property_compare_fcn_default() and the hook for "dns-data" was _nm_setting_property_compare_fcn_ignore(). That's wrong. _nm_setting_property_compare_fcn_default() converts the property to D-Bus and compares the GVariant. However, "dns" has to_dbus_only_in_manager_process set, so it wouldn't Fixes: 63eaf168d1b8 ('libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus')
2022-10-27 21:10:45 +02:00
NMTernary _nm_setting_ip_config_compare_fcn_dns(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil);
libnm: rename internal to/from dbus functions
2022-10-21 14:50:27 +02:00
gboolean _nm_sett_info_prop_missing_from_dbus_fcn_cloned_mac_address(
_NM_SETT_INFO_PROP_MISSING_FROM_DBUS_FCN_ARGS _nm_nil);
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
libnm: rename internal to/from dbus functions
2022-10-21 14:50:27 +02:00
GVariant *
_nm_sett_info_prop_to_dbus_fcn_cloned_mac_address(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil);
libnm: use macros function arguments for NMSettInfoPropertType These functions tend to have many arguments. They are also quite som boilerplate to implement the hundereds of properties we have, while we want that properties have common behaviors and similarities. Instead of repeatedly spelling out the function arguments, use a macro. Advantages: - the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this is an implementation of a property. You can now grep for these macros to find all implementation. That was previously rather imprecise, you could only `git grep '\.to_dbus_fcn'` to find the uses, but not the implementations. As the goal is to keep properties "similar", there is a desire to reduce the number of similar implementations and to find them. - changing the arguments now no longer will require you to go through all implementations. At least not, if you merely add an argument that has a reasonable default behavior and does not require explicit handling by most implementation. - it's convenient to be able to patch the argument list to let the compiler help to reason about something. For example, the "connection_dict" argument to from_dbus_fcn() is usually unused. If you'd like to find who uses it, rename the parameter, and review the (few) compiler errors. - it does save 573 LOC of boilerplate with no actual logic or useful information. I argue, that this simplifies the code and review, by increasing the relative amount of actually meaningful code. Disadvantages: - the user no longer directly sees the argument list. They would need cscope/ctags or an IDE to jump to the macro definition and conveniently see all arguments. Also use _nm_nil, so that clang-format interprets this as a function parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
libnm: rename internal to/from dbus functions
2022-10-21 14:50:27 +02:00
gboolean
_nm_sett_info_prop_from_dbus_fcn_cloned_mac_address(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil);
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: rework normalization of "wifi.mac-address-randomization" The previous code is not entirely obvious, because as always, verify() and normalize() must agree in what they are about to do. Make that clearer by adding _nm_setting_wireless_normalize_mac_address_randomization(), which evaluates the desired settings. This is the used both by verify() and normalize().
2023-12-12 19:36:35 +01:00
void _nm_setting_wireless_normalize_mac_address_randomization(
NMSettingWireless *s_wifi,
const char **out_cloned_mac_address,
NMSettingMacRandomization *out_mac_address_randomization);
/*****************************************************************************/
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