fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-20 11:40:14 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-netns.c

347 lines
10 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: GPL-2.0+
all: manually drop code comments with file description
2019-09-25 13:13:40 +02:00
/*
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
* Copyright (C) 2017 Red Hat, Inc.
*/
#include "nm-default.h"
#include "nm-netns.h"
shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" From the files under "shared/nm-utils" we build an internal library that provides glib-based helper utilities. Move the files of that basic library to a new subdirectory "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la" to "libnm-glib-aux.la". Reasons: - the name "utils" is overused in our code-base. Everything's an "utils". Give this thing a more distinct name. - there were additional files under "shared/nm-utils", which are not part of this internal library "libnm-utils-base.la". All the files that are part of this library should be together in the same directory, but files that are not, should not be there. - the new name should better convey what this library is and what is isn't: it's a set of utilities and helper functions that extend glib with funcitonality that we commonly need. There are still some files left under "shared/nm-utils". They have less a unifying propose to be in their own directory, so I leave them there for now. But at least they are separate from "shared/nm-glib-aux", which has a very clear purpose. (cherry picked from commit 80db06f768e47541eae7d66ef48fbe47bf1a69ce)
2019-04-15 08:16:00 +02:00
#include "nm-glib-aux/nm-dedup-multi.h"
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
#include "NetworkManagerUtils.h"
#include "nm-core-internal.h"
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
#include "nm-l3cfg.h"
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
#include "platform/nm-platform.h"
#include "platform/nmp-netns.h"
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
#include "platform/nmp-rules-manager.h"
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
/*****************************************************************************/
NM_GOBJECT_PROPERTIES_DEFINE_BASE (
PROP_PLATFORM,
);
typedef struct {
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
NMNetns *_self_signal_user_data;
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
NMPlatform *platform;
NMPNetns *platform_netns;
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
NMPRulesManager *rules_manager;
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
GHashTable *l3cfgs;
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
CList l3cfg_signal_pending_lst_head;
guint signal_pending_idle_id;
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
} NMNetnsPrivate;
struct _NMNetns {
GObject parent;
NMNetnsPrivate _priv;
};
struct _NMNetnsClass {
GObjectClass parent;
};
G_DEFINE_TYPE (NMNetns, nm_netns, G_TYPE_OBJECT);
#define NM_NETNS_GET_PRIVATE(self) _NM_GET_PRIVATE (self, NMNetns, NM_IS_NETNS)
/*****************************************************************************/
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
#define _NMLOG_DOMAIN LOGD_CORE
#define _NMLOG_PREFIX_NAME "netns"
#define _NMLOG(level, ...) \
G_STMT_START { \
nm_log ((level), (_NMLOG_DOMAIN), NULL, NULL, \
"netns["NM_HASH_OBFUSCATE_PTR_FMT"]: " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
NM_HASH_OBFUSCATE_PTR (self) \
_NM_UTILS_MACRO_REST(__VA_ARGS__)); \
} G_STMT_END
/*****************************************************************************/
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
NM_DEFINE_SINGLETON_GETTER (NMNetns, nm_netns_get, NM_TYPE_NETNS);
/*****************************************************************************/
NMPNetns *
nm_netns_get_platform_netns (NMNetns *self)
{
return NM_NETNS_GET_PRIVATE (self)->platform_netns;
}
NMPlatform *
nm_netns_get_platform (NMNetns *self)
{
return NM_NETNS_GET_PRIVATE (self)->platform;
}
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
NMPRulesManager *
nm_netns_get_rules_manager (NMNetns *self)
{
return NM_NETNS_GET_PRIVATE (self)->rules_manager;
}
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
NMDedupMultiIndex *
nm_netns_get_multi_idx (NMNetns *self)
{
return nm_platform_get_multi_idx (NM_NETNS_GET_PRIVATE (self)->platform);
}
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
/*****************************************************************************/
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
typedef struct {
int ifindex;
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
guint32 signal_pending_flag;
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
NML3Cfg *l3cfg;
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
CList signal_pending_lst;
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
} L3CfgData;
static void
_l3cfg_data_free (gpointer ptr)
{
L3CfgData *l3cfg_data = ptr;
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
c_list_unlink_stale (&l3cfg_data->signal_pending_lst);
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
nm_g_slice_free (l3cfg_data);
}
static void
_l3cfg_weak_notify (gpointer data,
GObject *where_the_object_was)
{
NMNetns *self = NM_NETNS (data);
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE(data);
NML3Cfg *l3cfg = NM_L3CFG (where_the_object_was);
int ifindex = nm_l3cfg_get_ifindex (l3cfg);
if (!g_hash_table_remove (priv->l3cfgs, &ifindex))
nm_assert_not_reached ();
if (NM_UNLIKELY (g_hash_table_size (priv->l3cfgs) == 0))
g_object_unref (self);
}
NML3Cfg *
nm_netns_access_l3cfg (NMNetns *self,
int ifindex)
{
NMNetnsPrivate *priv;
L3CfgData *l3cfg_data;
g_return_val_if_fail (NM_IS_NETNS (self), NULL);
g_return_val_if_fail (ifindex > 0, NULL);
priv = NM_NETNS_GET_PRIVATE (self);
l3cfg_data = g_hash_table_lookup (priv->l3cfgs, &ifindex);
if (l3cfg_data) {
nm_log_trace (LOGD_CORE,
"l3cfg["NM_HASH_OBFUSCATE_PTR_FMT",ifindex=%d] %s",
NM_HASH_OBFUSCATE_PTR (l3cfg_data->l3cfg),
ifindex,
"referenced");
return g_object_ref (l3cfg_data->l3cfg);
}
l3cfg_data = g_slice_new (L3CfgData);
*l3cfg_data = (L3CfgData) {
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
.ifindex = ifindex,
.l3cfg = nm_l3cfg_new (self, ifindex),
.signal_pending_lst = C_LIST_INIT (l3cfg_data->signal_pending_lst),
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
};
if (!g_hash_table_add (priv->l3cfgs, l3cfg_data))
nm_assert_not_reached ();
if (NM_UNLIKELY (g_hash_table_size (priv->l3cfgs) == 1))
g_object_ref (self);
g_object_weak_ref (G_OBJECT (l3cfg_data->l3cfg),
_l3cfg_weak_notify,
self);
/* Transfer ownership! We keep only a weak ref. */
return l3cfg_data->l3cfg;
}
/*****************************************************************************/
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
static gboolean
_platform_signal_on_idle_cb (gpointer user_data)
{
gs_unref_object NMNetns *self = g_object_ref (NM_NETNS (user_data));
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
L3CfgData *l3cfg_data;
while ((l3cfg_data = c_list_first_entry (&priv->l3cfg_signal_pending_lst_head, L3CfgData, signal_pending_lst))) {
c_list_unlink (&l3cfg_data->signal_pending_lst);
_nm_l3cfg_notify_platform_change_on_idle (l3cfg_data->l3cfg,
nm_steal_int (&l3cfg_data->signal_pending_flag));
}
priv->signal_pending_idle_id = 0;
return G_SOURCE_REMOVE;
}
static void
_platform_signal_cb (NMPlatform *platform,
int obj_type_i,
int ifindex,
gconstpointer platform_object,
int change_type_i,
NMNetns **p_self)
{
NMNetns *self = NM_NETNS (*p_self);
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
const NMPObjectType obj_type = obj_type_i;
l3cfg: track externally removed addresses/routes We want to allow the user to externally remove IP addresses and routes, and NetworkManager not re-adding them until a full reapply happens. For that, we need to keep track of IP addresses that were present, but no longer are.
2020-07-29 08:39:12 +02:00
const NMPlatformSignalChangeType change_type = change_type_i;
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
L3CfgData *l3cfg_data;
l3cfg_data = g_hash_table_lookup (priv->l3cfgs, &ifindex);
if (!l3cfg_data)
return;
l3cfg_data->signal_pending_flag |= nmp_object_type_to_flags (obj_type);
l3cfg: track externally removed addresses/routes We want to allow the user to externally remove IP addresses and routes, and NetworkManager not re-adding them until a full reapply happens. For that, we need to keep track of IP addresses that were present, but no longer are.
2020-07-29 08:39:12 +02:00
if (c_list_is_empty (&l3cfg_data->signal_pending_lst)) {
c_list_link_tail (&priv->l3cfg_signal_pending_lst_head, &l3cfg_data->signal_pending_lst);
if (priv->signal_pending_idle_id == 0)
priv->signal_pending_idle_id = g_idle_add (_platform_signal_on_idle_cb, self);
}
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
l3cfg: track externally removed addresses/routes We want to allow the user to externally remove IP addresses and routes, and NetworkManager not re-adding them until a full reapply happens. For that, we need to keep track of IP addresses that were present, but no longer are.
2020-07-29 08:39:12 +02:00
_nm_l3cfg_notify_platform_change (l3cfg_data->l3cfg,
change_type,
NMP_OBJECT_UP_CAST (platform_object));
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
}
/*****************************************************************************/
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
static void
set_property (GObject *object, guint prop_id,
const GValue *value, GParamSpec *pspec)
{
NMNetns *self = NM_NETNS (object);
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
switch (prop_id) {
case PROP_PLATFORM:
/* construct-only */
priv->platform = g_value_get_object (value) ?: NM_PLATFORM_GET;
if (!priv->platform)
g_return_if_reached ();
g_object_ref (priv->platform);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
/*****************************************************************************/
static void
nm_netns_init (NMNetns *self)
{
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
priv->_self_signal_user_data = self;
c_list_init (&priv->l3cfg_signal_pending_lst_head);
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
}
static void
constructed (GObject *object)
{
NMNetns *self = NM_NETNS (object);
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
if (!priv->platform)
g_return_if_reached ();
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
priv->l3cfgs = g_hash_table_new_full (nm_pint_hash, nm_pint_equals, _l3cfg_data_free, NULL);
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
priv->platform_netns = nm_platform_netns_get (priv->platform);
platform: drop track_default argument from nmp_rules_manager_new() All that setting track-default does, is calling nmp_rules_manager_track_default() when the rules are first accessed. That is not right API. Since nmp_rules_manager_track_default() is already public API (good), every caller that wishes this behavior should track these routes explicitly.
2019-04-10 12:52:56 +02:00
priv->rules_manager = nmp_rules_manager_new (priv->platform);
platform: support weakly tracked routing rules in NMPRulesManager Policy routing rules are global, and unlike routes not tied to an interface by ifindex. That means, while we take full control over all routes of an interface during a sync, we need to consider that multiple parties can contribute to the global set of rules. That might be muliple connection profiles providing the same rule, or rules that are added externally by the user. NMPRulesManager mediates for that. This is done by NMPRulesManager "tracking" rules. Rules that are not tracked by NMPRulesManager are completely ignored (and considered externally added). When tracking a rule, the caller provides a track-priority. If multiple parties track a rule, then the highest (absolute value of the) priority wins. If the highest track-priority is positive, NMPRulesManager will add the rule if it's not present. When the highest track-priority is negative, then NMPRulesManager will remove the rule if it's present (enforce its absence). The complicated part is, when a rule that was previously tracked becomes no longer tracked. In that case, we need to restore the previous state. If NetworkManager added the rule earlier, then untracking the rule NMPRulesManager will remove the rule again (restore its previous absent state). By default, if NetworkManager had a negative tracking-priority and removed the rule earlier (enforced it to be absent), then when the rule becomes no longer tracked, NetworkManager will not restore the rule. Consider: the user adds a rule externally, and then activates a profile that enforces the absence of the rule (causing NetworkManager to remove it). When deactivating the profile, by default NetworkManager will not restore such a rule! It's unclear whether that is a good idea, but it's also unclear why the rule is there and whether NetworkManager should really restore it. Add weakly tracked rules to account for that. A tracking-priority of zero indicates such weakly tracked rules. The only difference between an untracked rule and a weakly tracked rule is, that when NetworkManager earlier removed the rule (due to a negative tracking-priority), it *will* restore weakly tracked rules when the rules becomes no longer (negatively) tracked. And it attmpts to do that only once. Likewise, if the rule is weakly tracked and already exists when NMPRulesManager starts posively tracking the rule, then it would not remove again, when no longer positively tracking it.
2019-04-10 13:47:52 +02:00
policy-routing: take ownership of externally configured rules IP addresses, routes, TC and QDiscs are all tied to a certain interface. So when NetworkManager manages an interface, it can be confident that all related entires should be managed, deleted and modified by NetworkManager. Routing policy rules are global. For that we have NMPRulesManager which keeps track of whether NetworkManager owns a rule. This allows multiple connection profiles to specify the same rule, and NMPRulesManager can consolidate this information to know whether to add or remove the rule. NMPRulesManager would also support to explicitly block a rule by tracking it with negative priority. However that is still unused at the moment. All that devices do is to add rules (track with positive priority) and remove them (untrack) once the profile gets deactivated. As rules are not exclusively owned by NetworkManager, NetworkManager tries not to interfere with rules that it knows nothing about. That means in particular, when NetworkManager starts it will "weakly track" all rules that are present. "weakly track" is mostly interesting for two cases: - when NMPRulesManager had the same rule explicitly tracked (added) by a device, then deactivating the device will leave the rule in place. - when NMPRulesManager had the same rule explicitly blocked (tracked with negative priority), then it would restore the rule when that block gets removed (as said, currently nobody actually does this). Note that when restarting NetworkManager, then the device may stay and the rules kept. However after restart, NetworkManager no longer knows that it previously added this route, so it would weakly track it and never remove them again. That is a problem. Avoid that, by whenever explicitly tracking a rule we also make sure to no longer weakly track it. Most likely this rule was indeed previously managed by NetworkManager. If this was really a rule added by externally, then the user really should choose distinct rule priorities to avoid such conflicts altogether.
2019-07-12 11:19:43 +02:00
/* Weakly track the default rules with a dummy user-tag. These
* rules are always weekly tracked... */
platform: drop track_default argument from nmp_rules_manager_new() All that setting track-default does, is calling nmp_rules_manager_track_default() when the rules are first accessed. That is not right API. Since nmp_rules_manager_track_default() is already public API (good), every caller that wishes this behavior should track these routes explicitly.
2019-04-10 12:52:56 +02:00
nmp_rules_manager_track_default (priv->rules_manager,
AF_UNSPEC,
0,
nm_netns_parent_class /* static dummy user-tag */);
policy-routing: take ownership of externally configured rules IP addresses, routes, TC and QDiscs are all tied to a certain interface. So when NetworkManager manages an interface, it can be confident that all related entires should be managed, deleted and modified by NetworkManager. Routing policy rules are global. For that we have NMPRulesManager which keeps track of whether NetworkManager owns a rule. This allows multiple connection profiles to specify the same rule, and NMPRulesManager can consolidate this information to know whether to add or remove the rule. NMPRulesManager would also support to explicitly block a rule by tracking it with negative priority. However that is still unused at the moment. All that devices do is to add rules (track with positive priority) and remove them (untrack) once the profile gets deactivated. As rules are not exclusively owned by NetworkManager, NetworkManager tries not to interfere with rules that it knows nothing about. That means in particular, when NetworkManager starts it will "weakly track" all rules that are present. "weakly track" is mostly interesting for two cases: - when NMPRulesManager had the same rule explicitly tracked (added) by a device, then deactivating the device will leave the rule in place. - when NMPRulesManager had the same rule explicitly blocked (tracked with negative priority), then it would restore the rule when that block gets removed (as said, currently nobody actually does this). Note that when restarting NetworkManager, then the device may stay and the rules kept. However after restart, NetworkManager no longer knows that it previously added this route, so it would weakly track it and never remove them again. That is a problem. Avoid that, by whenever explicitly tracking a rule we also make sure to no longer weakly track it. Most likely this rule was indeed previously managed by NetworkManager. If this was really a rule added by externally, then the user really should choose distinct rule priorities to avoid such conflicts altogether.
2019-07-12 11:19:43 +02:00
/* Also weakly track all existing rules. These were added before NetworkManager
* starts, so they are probably none of NetworkManager's business.
*
* However note that during service restart, devices may stay up and rules kept.
* That means, after restart such rules may have been added by a previous run
* of NetworkManager, we just don't know.
*
* For that reason, whenever we will touch such rules later one, we make them
* fully owned and no longer weekly tracked. See %NMP_RULES_MANAGER_EXTERN_WEAKLY_TRACKED_USER_TAG. */
platform: support weakly tracked routing rules in NMPRulesManager Policy routing rules are global, and unlike routes not tied to an interface by ifindex. That means, while we take full control over all routes of an interface during a sync, we need to consider that multiple parties can contribute to the global set of rules. That might be muliple connection profiles providing the same rule, or rules that are added externally by the user. NMPRulesManager mediates for that. This is done by NMPRulesManager "tracking" rules. Rules that are not tracked by NMPRulesManager are completely ignored (and considered externally added). When tracking a rule, the caller provides a track-priority. If multiple parties track a rule, then the highest (absolute value of the) priority wins. If the highest track-priority is positive, NMPRulesManager will add the rule if it's not present. When the highest track-priority is negative, then NMPRulesManager will remove the rule if it's present (enforce its absence). The complicated part is, when a rule that was previously tracked becomes no longer tracked. In that case, we need to restore the previous state. If NetworkManager added the rule earlier, then untracking the rule NMPRulesManager will remove the rule again (restore its previous absent state). By default, if NetworkManager had a negative tracking-priority and removed the rule earlier (enforced it to be absent), then when the rule becomes no longer tracked, NetworkManager will not restore the rule. Consider: the user adds a rule externally, and then activates a profile that enforces the absence of the rule (causing NetworkManager to remove it). When deactivating the profile, by default NetworkManager will not restore such a rule! It's unclear whether that is a good idea, but it's also unclear why the rule is there and whether NetworkManager should really restore it. Add weakly tracked rules to account for that. A tracking-priority of zero indicates such weakly tracked rules. The only difference between an untracked rule and a weakly tracked rule is, that when NetworkManager earlier removed the rule (due to a negative tracking-priority), it *will* restore weakly tracked rules when the rules becomes no longer (negatively) tracked. And it attmpts to do that only once. Likewise, if the rule is weakly tracked and already exists when NMPRulesManager starts posively tracking the rule, then it would not remove again, when no longer positively tracking it.
2019-04-10 13:47:52 +02:00
nmp_rules_manager_track_from_platform (priv->rules_manager,
NULL,
AF_UNSPEC,
0,
policy-routing: take ownership of externally configured rules IP addresses, routes, TC and QDiscs are all tied to a certain interface. So when NetworkManager manages an interface, it can be confident that all related entires should be managed, deleted and modified by NetworkManager. Routing policy rules are global. For that we have NMPRulesManager which keeps track of whether NetworkManager owns a rule. This allows multiple connection profiles to specify the same rule, and NMPRulesManager can consolidate this information to know whether to add or remove the rule. NMPRulesManager would also support to explicitly block a rule by tracking it with negative priority. However that is still unused at the moment. All that devices do is to add rules (track with positive priority) and remove them (untrack) once the profile gets deactivated. As rules are not exclusively owned by NetworkManager, NetworkManager tries not to interfere with rules that it knows nothing about. That means in particular, when NetworkManager starts it will "weakly track" all rules that are present. "weakly track" is mostly interesting for two cases: - when NMPRulesManager had the same rule explicitly tracked (added) by a device, then deactivating the device will leave the rule in place. - when NMPRulesManager had the same rule explicitly blocked (tracked with negative priority), then it would restore the rule when that block gets removed (as said, currently nobody actually does this). Note that when restarting NetworkManager, then the device may stay and the rules kept. However after restart, NetworkManager no longer knows that it previously added this route, so it would weakly track it and never remove them again. That is a problem. Avoid that, by whenever explicitly tracking a rule we also make sure to no longer weakly track it. Most likely this rule was indeed previously managed by NetworkManager. If this was really a rule added by externally, then the user really should choose distinct rule priorities to avoid such conflicts altogether.
2019-07-12 11:19:43 +02:00
NMP_RULES_MANAGER_EXTERN_WEAKLY_TRACKED_USER_TAG);
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
G_OBJECT_CLASS (nm_netns_parent_class)->constructed (object);
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
g_signal_connect (priv->platform, NM_PLATFORM_SIGNAL_LINK_CHANGED, G_CALLBACK (_platform_signal_cb), &priv->_self_signal_user_data);
l3cfg: add nm_l3cfg_property_emit_register() API The NML3Cfg instance tracks and prepares the IP configuration. However, that is also partly exposed on other objects, like NMIP4Config's "route-data" property. Add an API, so that NMIP4Config can register itself to be notified when something relevant changes. This is an alternative to standard GObject properties and signals. They often seem more effort than worth. That is, because in this case, NMIP4Config.route-data has no other task then to re-emit the signal. So, to implement that with GObject properties/signals, we would have to add a property/signal to NML3Cfg, subscribe to it from NMIP4Config, and remit the signal. An alternative is to bind properties, but that would still be quite some extra code, and unclear that it would be simpler. Not to mention the overhead, as bindings are themself full GObject instances, that register to and emit signals by name.
2020-07-21 12:52:42 +02:00
g_signal_connect (priv->platform, NM_PLATFORM_SIGNAL_IP4_ROUTE_CHANGED, G_CALLBACK (_platform_signal_cb), &priv->_self_signal_user_data);
g_signal_connect (priv->platform, NM_PLATFORM_SIGNAL_IP6_ROUTE_CHANGED, G_CALLBACK (_platform_signal_cb), &priv->_self_signal_user_data);
l3cfg: track externally removed addresses/routes We want to allow the user to externally remove IP addresses and routes, and NetworkManager not re-adding them until a full reapply happens. For that, we need to keep track of IP addresses that were present, but no longer are.
2020-07-29 08:39:12 +02:00
g_signal_connect (priv->platform, NM_PLATFORM_SIGNAL_IP4_ADDRESS_CHANGED, G_CALLBACK (_platform_signal_cb), &priv->_self_signal_user_data);
g_signal_connect (priv->platform, NM_PLATFORM_SIGNAL_IP6_ADDRESS_CHANGED, G_CALLBACK (_platform_signal_cb), &priv->_self_signal_user_data);
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
}
NMNetns *
nm_netns_new (NMPlatform *platform)
{
return g_object_new (NM_TYPE_NETNS,
NM_NETNS_PLATFORM, platform,
NULL);
}
static void
dispose (GObject *object)
{
NMNetns *self = NM_NETNS (object);
NMNetnsPrivate *priv = NM_NETNS_GET_PRIVATE (self);
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
nm_assert (nm_g_hash_table_size (priv->l3cfgs) == 0);
l3cfg: notify NML3Cfg about NMPlatform changes in an idle handler We need to react to platform changes. Also, we usually want to delay the reaction to an idle handler. Instead of subscribing each NML3Cfg instance itself to platform changes, let only NMNetns do that. The goal is of course that each platform event only needs to notify the NML3Cfg instance, which collects the events and schedules them on the idle handler.
2020-07-21 11:21:44 +02:00
nm_assert (c_list_is_empty (&priv->l3cfg_signal_pending_lst_head));
nm_clear_g_source (&priv->signal_pending_idle_id);
if (priv->platform)
g_signal_handlers_disconnect_by_data (priv->platform, &priv->_self_signal_user_data);
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
g_clear_object (&priv->platform);
core: add "nm-l3cfg.[hc]"
2020-07-18 19:01:04 +02:00
g_clear_pointer (&priv->l3cfgs, g_hash_table_unref);
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
platform: add NMPRulesManager for syncing routing rules Routing rules are unlike addresses or routes not tied to an interface. NetworkManager thinks in terms of connection profiles. That works well for addresses and routes, as one profile configures addresses and routes for one device. For example, when activating a profile on a device, the configuration does not interfere with the addresses/routes of other devices. That is not the case for routing rules, which are global, netns-wide entities. When one connection profile specifies rules, then this per-device configuration must be merged with the global configuration. And when a device disconnects later, the rules must be removed. Add a new NMPRulesManager API to track/untrack routing rules. Devices can register/add there the routing rules they require. And the sync method will apply the configuration. This is be implemented on top of NMPlatform's caching API.
2019-03-11 11:37:40 +01:00
nm_clear_pointer (&priv->rules_manager, nmp_rules_manager_unref);
core: add NMNetns to bundle platform and route managers NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons instances. Users of those are for example NMDevice, which registers to GObject signals of both NMPlatform and NMRouteManager. Hence, as NMDevice:dispose() disconnects the signal handlers, it must ensure that those singleton instances live longer then the NMDevice instance. That is usually accomplished by having users of singleton instances own a reference to those instances. For NMDevice that effectively means that it shall own a reference to several singletons. NMPlatform, NMRouteManager, and NMDefaultRouteManager are all per-namespace. In general it doesn't make sense to have more then one instances of these per name space. Nnote that currently we don't support multiple namespaces yet. If we will ever support multiple namespaces, then a NMDevice would have a reference to all of these manager instances. Hence, introduce a new class NMNetns which bundles them together. (cherry picked from commit 0af2f5c28b7646c687b5180a45a9124d62c0dfac)
2017-04-17 18:40:52 +02:00
G_OBJECT_CLASS (nm_netns_parent_class)->dispose (object);
}
static void
nm_netns_class_init (NMNetnsClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->constructed = constructed;
object_class->set_property = set_property;
object_class->dispose = dispose;
obj_properties[PROP_PLATFORM] =
g_param_spec_object (NM_NETNS_PLATFORM, "", "",
NM_TYPE_PLATFORM,
G_PARAM_WRITABLE |
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
}
Reference in a new issue Copy permalink