fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-28 01:28:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/devices/nm-device-vlan.c

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

689 lines
25 KiB
C
Raw Normal View History

all: unify comment style for SPDX-License-Identifier tag Our coding style recommends C style comments (/* */) instead of C++ (//). Also, systemd (which we partly fork) uses C style comments for the SPDX-License-Identifier. Unify the style. $ sed -i '1 s#// SPDX-License-Identifier: \([^ ]\+\)$#/* SPDX-License-Identifier: \1 */#' -- $(git ls-files -- '*.[hc]' '*.[hc]pp')
2020-09-29 16:42:22 +02:00
/* SPDX-License-Identifier: GPL-2.0+ */
all: manually drop code comments with file description
2019-09-25 13:13:40 +02: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 - 2012 Red Hat, Inc.
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
*/
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-default.h"
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
device: use NMSettings directly instead of NMConnectionProvider in subclasses Instead of accessing the singleton getter nm_settings_get(), obtain the settings instance from the device instance itself via nm_device_get_settings().
2016-05-16 19:01:37 +02:00
#include "nm-device-vlan.h"
vlan: add missing includes
2012-03-02 08:56:46 +01:00
#include <sys/socket.h>
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
#include "nm-manager.h"
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
#include "nm-utils.h"
#include "NetworkManagerUtils.h"
#include "nm-device-private.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "settings/nm-settings.h"
core: rename "nm-activation-request.[hc]" for NMActRequest "nm-activation-request.[hc]" contains NMActRequest. It should thus be called "nm-act-request.[hc]".
2016-09-28 19:37:10 +02:00
#include "nm-act-request.h"
core: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
#include "nm-ip4-config.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "platform/nm-platform.h"
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
#include "nm-device-factory.h"
#include "nm-manager.h"
libnm-core: add nm-core-types.h, remove cross-includes Add nm-core-types.h, typedefing all of the GObject types in libnm-core; this is needed so that nm-setting.h can reference NMConnection in addition to nm-connection.h referencing NMSetting. Removing the cross-includes from the various headers causes lots of fallout elsewhere. (In particular, nm-utils.h used to include nm-connection.h, which included every setting header, so any file that included nm-utils.h automatically got most of the rest of libnm-core without needing to pay attention to specifics.) Fix this up by including nm-core-internal.h from those files that are now missing includes.
2014-10-21 22:09:52 -04:00
#include "nm-core-internal.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "platform/nmp-object.h"
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
device: improve "nm-device-logging.h" to support a self pointer of NMDevice type "nm-device-logging.h" defines logging macros for a NMDevice instance. It also expects a "self" variable in the call environment, and that variable had to be in the type of NMDevice or the NMDevice subclass. Extend the macro foo, so that @self can be either a NMDevice* pointer or a NMDevice$SUBTYPE. Of course, that would have always been possible, if we would simply cast to "(NMDevice *)" where we need it. The trick is that the macro only works if @self is one of the two expected types, and not some arbitrary unrelated type.
2020-11-06 18:22:11 +01:00
#define _NMLOG_DEVICE_TYPE NMDeviceVlan
logging: use new logging macros in NMDevice subclasses Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-02 15:14:26 +02:00
#include "nm-device-logging.h"
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
/*****************************************************************************/
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
NM_GOBJECT_PROPERTIES_DEFINE(NMDeviceVlan, PROP_VLAN_ID, );
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
typedef struct {
core: always use gulong to store signal handler ids We inconsistently use gulong,guint,int types to store signal handler id, but the type returned by g_signal_connect() is a gulong. This has no practical consequences because a int/guint is enough to store the value, however it is better to use a consistent type, also because nm_clear_g_signal_handler() accepts a pointer to the signal id and thus it must be always called with the same pointer type.
2016-01-04 10:29:06 +01:00
gulong parent_state_id;
gulong parent_hwaddr_id;
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
gulong parent_mtu_id;
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
guint vlan_id;
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
} NMDeviceVlanPrivate;
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
struct _NMDeviceVlan {
NMDevice parent;
NMDeviceVlanPrivate _priv;
};
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
struct _NMDeviceVlanClass {
NMDeviceClass parent;
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
};
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
G_DEFINE_TYPE(NMDeviceVlan, nm_device_vlan, NM_TYPE_DEVICE)
shared: make NM_CONSTCAST() macro variadic We need to pass more alias-types. Instead of having numbered versions, use variadic number of macro arguments. Also, fix build failure with old compiler: In file included from src/nm-ip6-config.c:24: ./src/nm-ip6-config.h:44:29: error: controlling expression type 'typeof (ipconf_iter->current->obj)' (aka 'const void *const') not compatible with any generic association type *out_address = has_next ? NMP_OBJECT_CAST_IP6_ADDRESS (ipconf_iter->current->obj) : NULL; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: b1810d7a68d188aa8f36a0e23a7be705a742b1aa
2017-11-09 11:42:24 +01:00
#define NM_DEVICE_VLAN_GET_PRIVATE(self) \
_NM_GET_PRIVATE(self, NMDeviceVlan, NM_IS_DEVICE_VLAN, NMDevice)
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
trivial: move code
2015-04-29 10:06:51 +02:00
static void
parent_state_changed(NMDevice * parent,
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason,
gpointer user_data)
{
NMDeviceVlan *self = NM_DEVICE_VLAN(user_data);
/* We'll react to our own carrier state notifications. Ignore the parent's. */
device: mark uses of device's state-reason with nm_device_state_reason_check() The state-change of a device has a reason argument, which is mostly for information only. There are many places in code that are the source of a state-reason. Mostly these are calls to: - nm_device_state_changed() - nm_device_queue_state() - nm_device_queue_recheck_available() - nm_device_set_unmanaged_by_*() - nm_device_master_release_one_slave() - nm_device_ip_method_failed() - nm_modem_emit_prepare_result() - nm_modem_emit_ppp_failed() - nm_manager_deactivate_connection() - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*); However, there are a few places in code that look at the reason to decide how to proceed. I think this is a bad pattern, because cause and effect are decoupled and it gets hard to understand where a certain reason is set and what consequences that has. Add a nop-function nm_device_state_reason_check() to mark all uses of the device state reason that derive decisions from it. That is, highlight the "effect" part.
2017-02-23 15:19:03 +01:00
if (nm_device_state_reason_check(reason) == NM_DEVICE_STATE_REASON_CARRIER)
trivial: move code
2015-04-29 10:06:51 +02:00
return;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags(NM_DEVICE(self),
NM_UNMANAGED_PARENT,
!nm_device_get_managed(parent, FALSE),
reason);
trivial: move code
2015-04-29 10:06:51 +02:00
}
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
static void
parent_mtu_maybe_changed(NMDevice *parent, GParamSpec *pspec, gpointer user_data)
{
/* the MTU of a VLAN device is limited by the parent's MTU.
*
* When the parent's MTU changes, try to re-set the MTU. */
nm_device_commit_mtu(user_data);
}
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
static void
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
parent_hwaddr_maybe_changed(NMDevice *parent, GParamSpec *pspec, gpointer user_data)
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
{
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
NMDevice * device = NM_DEVICE(user_data);
NMDeviceVlan * self = NM_DEVICE_VLAN(device);
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
NMConnection * connection;
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
const char * new_mac, *old_mac;
device/vlan: reapply IPv6 configuration after MAC change https://bugzilla.redhat.com/show_bug.cgi?id=1286105
2016-01-11 11:05:11 +01:00
NMSettingIPConfig *s_ip6;
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
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
/* Never touch assumed devices */
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external_or_assume(device))
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
return;
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
core: vlan: avoid unneeded casts
2018-05-26 14:59:17 +02:00
connection = nm_device_get_applied_connection(device);
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
if (!connection)
return;
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
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
/* Update the VLAN MAC only if configuration does not specify one */
core: vlan: avoid unneeded casts
2018-05-26 14:59:17 +02:00
if (nm_device_hw_addr_is_explict(device))
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
return;
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
core: vlan: avoid unneeded casts
2018-05-26 14:59:17 +02:00
old_mac = nm_device_get_hw_address(device);
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
new_mac = nm_device_get_hw_address(parent);
if (nm_streq0(old_mac, new_mac))
return;
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
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
_LOGD(LOGD_VLAN,
"parent hardware address changed to %s%s%s",
NM_PRINT_FMT_QUOTE_STRING(new_mac));
if (new_mac) {
core: vlan: avoid unneeded casts
2018-05-26 14:59:17 +02:00
nm_device_hw_addr_set(device, new_mac, "vlan-parent", TRUE);
device: vlan: restart ARP announcement after we change MAC After the parent MAC address changes and we update the VLAN MAC, also restart ARP announcement to notify neighbors of the new address mapping.
2018-05-26 15:13:19 +02:00
nm_device_arp_announce(device);
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
/* When changing the hw address the interface is taken down,
* removing the IPv6 configuration; reapply it.
*/
s_ip6 = nm_connection_get_setting_ip6_config(connection);
if (s_ip6)
device: merge nm_device_reactivate_ip_config() implementations for IPv4/IPv6
2020-10-29 12:50:39 +01:00
nm_device_reactivate_ip_config(device, AF_INET6, s_ip6, s_ip6);
device/vlan: update VLAN MAC address when parent's one changes When a VLAN has a bond as parent device the MAC address of the bond may change when other devices are enslaved and then the VLAN would have a MAC which is different from parent's one. Let the VLAN device listen for changes in hw-address property of parent and update its MAC address accordingly. https://bugzilla.redhat.com/show_bug.cgi?id=1264322
2015-10-06 15:21:29 +02:00
}
}
trivial: move code
2015-04-29 10:06:51 +02:00
static void
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_changed_notify(NMDevice *device,
int old_ifindex,
NMDevice *old_parent,
int new_ifindex,
NMDevice *new_parent)
trivial: move code
2015-04-29 10:06:51 +02:00
{
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDeviceVlan * self = NM_DEVICE_VLAN(device);
vlan: don't fail if parent isn't found at construct time for existing devices For existing devices, depending on the order that netlink sends interfaces to us, the parent may be found after the VLAN interface and not be available when the VLAN interface is constructed. Instead of failing construction, when a NMDeviceVlan has no parent keep it unavailable for activation. Then have the Manager notify existing devices when a new device is found, and let NMDeviceVlan find the parent later and become available via that mechanism. This doesn't apply to VLANs created by NM itself, because the kernel requires a parent ifindex when creating a VLAN device. Thus this fix only applies to VLANs created outside NetworkManager, or existing when NM starts up.
2015-04-13 11:43:12 -05:00
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE(self);
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NM_DEVICE_CLASS(nm_device_vlan_parent_class)
->parent_changed_notify(device, old_ifindex, old_parent, new_ifindex, new_parent);
trivial: move code
2015-04-29 10:06:51 +02:00
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
/* note that @self doesn't have to clear @parent_state_id on dispose,
* because NMDevice's dispose() will unset the parent, which in turn calls
* parent_changed_notify(). */
nm_clear_g_signal_handler(old_parent, &priv->parent_state_id);
nm_clear_g_signal_handler(old_parent, &priv->parent_hwaddr_id);
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
nm_clear_g_signal_handler(old_parent, &priv->parent_mtu_id);
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
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (new_parent) {
priv->parent_state_id = g_signal_connect(new_parent,
core: use define for NMDevice's "state-changed" signal name
2015-12-07 19:42:59 +01:00
NM_DEVICE_STATE_CHANGED,
trivial: move code
2015-04-29 10:06:51 +02:00
G_CALLBACK(parent_state_changed),
device);
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
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
priv->parent_hwaddr_id = g_signal_connect(new_parent,
"notify::" NM_DEVICE_HW_ADDRESS,
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
G_CALLBACK(parent_hwaddr_maybe_changed),
device);
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_hwaddr_maybe_changed(new_parent, NULL, self);
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
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
priv->parent_mtu_id = g_signal_connect(new_parent,
"notify::" NM_DEVICE_MTU,
G_CALLBACK(parent_mtu_maybe_changed),
device);
parent_mtu_maybe_changed(new_parent, NULL, self);
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
vlan: don't fail if parent isn't found at construct time for existing devices For existing devices, depending on the order that netlink sends interfaces to us, the parent may be found after the VLAN interface and not be available when the VLAN interface is constructed. Instead of failing construction, when a NMDeviceVlan has no parent keep it unavailable for activation. Then have the Manager notify existing devices when a new device is found, and let NMDeviceVlan find the parent later and become available via that mechanism. This doesn't apply to VLANs created by NM itself, because the kernel requires a parent ifindex when creating a VLAN device. Thus this fix only applies to VLANs created outside NetworkManager, or existing when NM starts up.
2015-04-13 11:43:12 -05:00
/* Set parent-dependent unmanaged flag */
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
nm_device_set_unmanaged_by_flags(device,
NM_UNMANAGED_PARENT,
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
!nm_device_get_managed(new_parent, FALSE),
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
NM_DEVICE_STATE_REASON_PARENT_MANAGED_CHANGED);
trivial: move code
2015-04-29 10:06:51 +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
vlan: don't fail if parent isn't found at construct time for existing devices For existing devices, depending on the order that netlink sends interfaces to us, the parent may be found after the VLAN interface and not be available when the VLAN interface is constructed. Instead of failing construction, when a NMDeviceVlan has no parent keep it unavailable for activation. Then have the Manager notify existing devices when a new device is found, and let NMDeviceVlan find the parent later and become available via that mechanism. This doesn't apply to VLANs created by NM itself, because the kernel requires a parent ifindex when creating a VLAN device. Thus this fix only applies to VLANs created outside NetworkManager, or existing when NM starts up.
2015-04-13 11:43:12 -05:00
/* Recheck availability now that the parent has changed */
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (new_ifindex > 0) {
nm_device_queue_recheck_available(device,
NM_DEVICE_STATE_REASON_PARENT_CHANGED,
NM_DEVICE_STATE_REASON_PARENT_CHANGED);
}
trivial: move code
2015-04-29 10:06:51 +02:00
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
static void
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
update_properties(NMDevice *device)
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
{
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
NMDeviceVlanPrivate * priv;
const NMPlatformLink * plink = NULL;
const NMPlatformLnkVlan *plnk = NULL;
int ifindex;
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
int parent_ifindex = 0;
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
guint vlan_id;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
g_return_if_fail(NM_IS_DEVICE_VLAN(device));
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
all: drop explicit casts from _GET_PRIVATE() macro calls The _GET_PRIVATE() macros are all implemented based on _NM_GET_PRIVATE(). That macro tries to be more type safe and uses _Generic() to do the right thing. Explicitly casting is not only unnecessary, it defeats these (static) type checks. Don't do that.
2020-02-14 10:50:25 +01:00
priv = NM_DEVICE_VLAN_GET_PRIVATE(device);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
ifindex = nm_device_get_ifindex(device);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
if (ifindex > 0)
device: don't use platform singleton getter in device subclasses Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get the platform singleton instance. For one, this is a step towards supporting namespaces, where we need to use different NMNetns/NMPlatform instances depending on in which namespace the device lives. Also, we should reduce our use of singletons. They are difficult to coordinate on shutdown. Instead there should be a clear order of dependencies, expressed by owning a reference to those singelton instances. We already own a reference to the platform singelton, so use it and avoid NM_PLATFORM_GET. (cherry picked from commit 94d9ee129d85ff926a10de78fedcc6b57cdcdb19)
2017-04-18 12:09:02 +02:00
plnk = nm_platform_link_get_lnk_vlan(nm_device_get_platform(device), ifindex, &plink);
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (plnk && plink->parent > 0)
parent_ifindex = plink->parent;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
g_object_freeze_notify((GObject *) device);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
nm_device_parent_set_ifindex(device, parent_ifindex);
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
vlan_id = plnk ? plnk->id : 0;
if (vlan_id != priv->vlan_id) {
priv->vlan_id = vlan_id;
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
_notify((NMDeviceVlan *) device, PROP_VLAN_ID);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
g_object_thaw_notify((GObject *) device);
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
static void
device/vlan: update vlan properties when link changes For example, when the parent link is moved to a different netns, we must update (clear) the vlan's parent.
2017-01-02 15:55:23 +01:00
link_changed(NMDevice *device, const NMPlatformLink *pllink)
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
{
device/vlan: update vlan properties when link changes For example, when the parent link is moved to a different netns, we must update (clear) the vlan's parent.
2017-01-02 15:55:23 +01:00
NM_DEVICE_CLASS(nm_device_vlan_parent_class)->link_changed(device, pllink);
update_properties(device);
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
static gboolean
create_and_realize(NMDevice * device,
NMConnection * connection,
NMDevice * parent,
platform: return pointer to NMPlatformLink object for add functions Let the link-add functions return the internal pointer to the platform link object. Similar to link-get, which doesn't copy the link either. Also adjust the sole users of the add-functions (create-and-realize) to take the pointer. Eventually we still copy the returned data, because accessing platform can invalidate the returned pointer. Thus we don't actually safe any copying by this (at least every use of the function currently leads to the data being copied). Still change it, because I think the API of NMPlatform should look like that.
2015-12-09 15:13:57 +01:00
const NMPlatformLink **out_plink,
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
GError ** error)
{
all: drop explicit casts from _GET_PRIVATE() macro calls The _GET_PRIVATE() macros are all implemented based on _NM_GET_PRIVATE(). That macro tries to be more type safe and uses _Generic() to do the right thing. Explicitly casting is not only unnecessary, it defeats these (static) type checks. Don't do that.
2020-02-14 10:50:25 +01:00
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE(device);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
const char * iface = nm_device_get_iface(device);
NMSettingVlan * s_vlan;
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
int parent_ifindex;
guint vlan_id;
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
int r;
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
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
s_vlan = nm_connection_get_setting_vlan(connection);
g_assert(s_vlan);
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
device: check for a parent device The device creation can be attempted if the name can be determined. It alone is doesn't mean that there's a parent device -- the name could just have been hardcoded in the connection. NetworkManager[21519]: nm_device_get_ifindex: assertion 'NM_IS_DEVICE (self)' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046 #1 0x00007ffff4ec8a3f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079 #2 0x00005555555d2090 in nm_device_get_ifindex (self=0x0) at devices/nm-device.c:562 #3 0x00005555555ef77a in nm_device_supports_vlans (self=0x0) at devices/nm-device.c:9865 #4 0x00005555555bf2f9 in create_and_realize (device=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, out_plink=0x7fffffffd5f8, error=0x7fffffffd700) at devices/nm-device-vlan.c:225 #5 0x00005555555d5757 in nm_device_create_and_realize (self=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, error=0x7fffffffd700) at devices/nm-device.c:1783 #6 0x0000555555688601 in system_create_virtual_device (self=0x555555af51c0 [NMManager], connection=0x555555b451e0) at nm-manager.c:1120 #7 0x000055555568894e in connection_changed (settings=0x555555ae8220 [NMSettings], connection=0x555555b451e0, manager=0x555555af51c0 [NMManager]) at nm-manager.c:1172 #8 0x0000555555693448 in nm_manager_start (self=0x555555af51c0 [NMManager], error=0x7fffffffda30) at nm-manager.c:4466 #9 0x00005555555d166f in main (argc=1, argv=0x7fffffffdba8) at main.c:454 (gdb) Fixes: 332994f1b19ded7cb343ef573443916bab05aaec
2016-04-19 12:02:02 +02:00
if (!parent) {
manager: downgrade error message for missing dependencies At startup the manager tries to create virtual devices without a specific order and spits warnings when a device can't be realized because the parent device is not yet created. These failures are not something the user should worry about because the creation will be retried when the parent appears. A better approach is to return an error code from the device's create_and_realize() telling that it failed because the parent doesn't exist. In this way, the manager knows that the device isn't ready and can avoid printing warning messages.
2017-09-14 09:26:51 +02:00
g_set_error(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_MISSING_DEPENDENCIES,
device: check for a parent device The device creation can be attempted if the name can be determined. It alone is doesn't mean that there's a parent device -- the name could just have been hardcoded in the connection. NetworkManager[21519]: nm_device_get_ifindex: assertion 'NM_IS_DEVICE (self)' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046 #1 0x00007ffff4ec8a3f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079 #2 0x00005555555d2090 in nm_device_get_ifindex (self=0x0) at devices/nm-device.c:562 #3 0x00005555555ef77a in nm_device_supports_vlans (self=0x0) at devices/nm-device.c:9865 #4 0x00005555555bf2f9 in create_and_realize (device=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, out_plink=0x7fffffffd5f8, error=0x7fffffffd700) at devices/nm-device-vlan.c:225 #5 0x00005555555d5757 in nm_device_create_and_realize (self=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, error=0x7fffffffd700) at devices/nm-device.c:1783 #6 0x0000555555688601 in system_create_virtual_device (self=0x555555af51c0 [NMManager], connection=0x555555b451e0) at nm-manager.c:1120 #7 0x000055555568894e in connection_changed (settings=0x555555ae8220 [NMSettings], connection=0x555555b451e0, manager=0x555555af51c0 [NMManager]) at nm-manager.c:1172 #8 0x0000555555693448 in nm_manager_start (self=0x555555af51c0 [NMManager], error=0x7fffffffda30) at nm-manager.c:4466 #9 0x00005555555d166f in main (argc=1, argv=0x7fffffffdba8) at main.c:454 (gdb) Fixes: 332994f1b19ded7cb343ef573443916bab05aaec
2016-04-19 12:02:02 +02:00
"VLAN devices can not be created without a parent interface");
return FALSE;
}
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
device: skip creating VLAN devices if parent device is not ready yet do a check on parent ifindex before calling "nm_device_supports_vlans" otherwise if the parent device is a software device and its ifindex member has not been updated yet we will trigger the g_return_if_fail statement in "nmp_cache_lookup_entry_link". This has been osserved in NetworkManager CI test suite, on NetworkManager boot, during the creation of a vlan on top of a bond interface. CI test: vlan_update_mac_from_bond [...] <info> [1503323670.0229] manager: (bond0): new Bond device (/org/freedesktop/NetworkManager/Devices/23) <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): constructed (NMDeviceVlan) <debug> [1503323670.0231] manager: (vlan-vlan10) create virtual device vlan10 <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping=0x1]) <trace> [1503323670.0235] exported-object[0x555555c3e320]: export: "/org/freedesktop/NetworkManager/Devices/24" <trace> [1503323670.0235] properties-changed[0x555555c3e320]: ignoring notification for prop g-object-path on type NMDeviceVlan <trace> [1503323670.0236] properties-changed[0x555555c3e320]: ignoring notification for prop path on type NMDeviceVlan <info> [1503323670.0237] manager: (vlan10): new VLAN device (/org/freedesktop/NetworkManager/Devices/24) <debug> [1503323670.0239] device[0x555555c3e320] (vlan10): create (is nm-owned) Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 1086 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff5ce3643 in g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 #1 0x00007ffff5ce37bf in g_log (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5d51190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007ffff5ce37f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", pretty_function=pretty_function@entry=0x5555557b2a20 <__func__.32407> "nmp_cache_lookup_entry_link", expression=expression@entry=0x5555557b1037 "ifindex > 0") at gmessages.c:1128 #3 0x000055555566688a in nmp_cache_lookup_entry_link (cache=0x555555a780f0, ifindex=<optimized out>) at src/platform/nmp-object.c:1449 #4 0x00005555556668f9 in nmp_cache_lookup_link (cache=<optimized out>, ifindex=ifindex@entry=0) at src/platform/nmp-object.c:1464 #5 0x00005555556515e9 in nm_platform_link_get_obj (self=self@entry=0x555555a88880 [NMLinuxPlatform], ifindex=ifindex@entry=0, visible_only=visible_only@entry=1) at src/platform/nm-platform.c:618 #6 0x0000555555633e91 in link_supports_vlans (platform=0x555555a88880 [NMLinuxPlatform], ifindex=0) at src/platform/nm-linux-platform.c:4482 #7 0x00005555556d6d41 in create_and_realize (device=0x555555c3e320 [NMDeviceVlan], connection=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], out_plink=0x7fffffffe1f8, error=0x7fffffffe358) at src/devices/nm-device-vlan.c:239 #8 0x00005555556b934c in nm_device_create_and_realize (self=self@entry=0x555555c3e320 [NMDeviceVlan], connection=connection@entry=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe358) at src/devices/nm-device.c:2946 #9 0x00005555555b84c7 in connection_changed (connection=0x7fffdc007890, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1381 #10 0x00005555555b84c7 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007890) at src/nm-manager.c:1431 #11 0x00005555555b9130 in retry_connections_for_parent_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond]) at src/nm-manager.c:1416 #12 0x00005555555b95c7 in add_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe598) at src/nm-manager.c:2238 #13 0x00005555555b83e1 in connection_changed (connection=0x7fffdc007b30, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1352 #14 0x00005555555b83e1 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007b30) at src/nm-manager.c:1431 #15 0x00005555555be25b in nm_manager_start (self=0x555555ab1070 [NMManager], error=error@entry=0x7fffffffe720) at src/nm-manager.c:5202 #16 0x0000555555586b13 in main (argc=1, argv=0x7fffffffe888) at src/main.c:413
2017-08-21 17:41:29 +02:00
parent_ifindex = nm_device_get_ifindex(parent);
if (parent_ifindex <= 0) {
manager: downgrade error message for missing dependencies At startup the manager tries to create virtual devices without a specific order and spits warnings when a device can't be realized because the parent device is not yet created. These failures are not something the user should worry about because the creation will be retried when the parent appears. A better approach is to return an error code from the device's create_and_realize() telling that it failed because the parent doesn't exist. In this way, the manager knows that the device isn't ready and can avoid printing warning messages.
2017-09-14 09:26:51 +02:00
g_set_error(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_MISSING_DEPENDENCIES,
vlan: improve error message on missing parent ifindex The message should only tell what went wrong.
2017-09-14 10:25:36 +02:00
"cannot retrieve ifindex of interface %s (%s)",
device: skip creating VLAN devices if parent device is not ready yet do a check on parent ifindex before calling "nm_device_supports_vlans" otherwise if the parent device is a software device and its ifindex member has not been updated yet we will trigger the g_return_if_fail statement in "nmp_cache_lookup_entry_link". This has been osserved in NetworkManager CI test suite, on NetworkManager boot, during the creation of a vlan on top of a bond interface. CI test: vlan_update_mac_from_bond [...] <info> [1503323670.0229] manager: (bond0): new Bond device (/org/freedesktop/NetworkManager/Devices/23) <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): constructed (NMDeviceVlan) <debug> [1503323670.0231] manager: (vlan-vlan10) create virtual device vlan10 <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping=0x1]) <trace> [1503323670.0235] exported-object[0x555555c3e320]: export: "/org/freedesktop/NetworkManager/Devices/24" <trace> [1503323670.0235] properties-changed[0x555555c3e320]: ignoring notification for prop g-object-path on type NMDeviceVlan <trace> [1503323670.0236] properties-changed[0x555555c3e320]: ignoring notification for prop path on type NMDeviceVlan <info> [1503323670.0237] manager: (vlan10): new VLAN device (/org/freedesktop/NetworkManager/Devices/24) <debug> [1503323670.0239] device[0x555555c3e320] (vlan10): create (is nm-owned) Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 1086 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff5ce3643 in g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 #1 0x00007ffff5ce37bf in g_log (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5d51190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007ffff5ce37f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", pretty_function=pretty_function@entry=0x5555557b2a20 <__func__.32407> "nmp_cache_lookup_entry_link", expression=expression@entry=0x5555557b1037 "ifindex > 0") at gmessages.c:1128 #3 0x000055555566688a in nmp_cache_lookup_entry_link (cache=0x555555a780f0, ifindex=<optimized out>) at src/platform/nmp-object.c:1449 #4 0x00005555556668f9 in nmp_cache_lookup_link (cache=<optimized out>, ifindex=ifindex@entry=0) at src/platform/nmp-object.c:1464 #5 0x00005555556515e9 in nm_platform_link_get_obj (self=self@entry=0x555555a88880 [NMLinuxPlatform], ifindex=ifindex@entry=0, visible_only=visible_only@entry=1) at src/platform/nm-platform.c:618 #6 0x0000555555633e91 in link_supports_vlans (platform=0x555555a88880 [NMLinuxPlatform], ifindex=0) at src/platform/nm-linux-platform.c:4482 #7 0x00005555556d6d41 in create_and_realize (device=0x555555c3e320 [NMDeviceVlan], connection=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], out_plink=0x7fffffffe1f8, error=0x7fffffffe358) at src/devices/nm-device-vlan.c:239 #8 0x00005555556b934c in nm_device_create_and_realize (self=self@entry=0x555555c3e320 [NMDeviceVlan], connection=connection@entry=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe358) at src/devices/nm-device.c:2946 #9 0x00005555555b84c7 in connection_changed (connection=0x7fffdc007890, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1381 #10 0x00005555555b84c7 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007890) at src/nm-manager.c:1431 #11 0x00005555555b9130 in retry_connections_for_parent_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond]) at src/nm-manager.c:1416 #12 0x00005555555b95c7 in add_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe598) at src/nm-manager.c:2238 #13 0x00005555555b83e1 in connection_changed (connection=0x7fffdc007b30, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1352 #14 0x00005555555b83e1 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007b30) at src/nm-manager.c:1431 #15 0x00005555555be25b in nm_manager_start (self=0x555555ab1070 [NMManager], error=error@entry=0x7fffffffe720) at src/nm-manager.c:5202 #16 0x0000555555586b13 in main (argc=1, argv=0x7fffffffe888) at src/main.c:413
2017-08-21 17:41:29 +02:00
nm_device_get_iface(parent),
nm_device_get_type_desc(parent));
return FALSE;
}
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
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
if (!nm_device_supports_vlans(parent)) {
g_set_error(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"no support for VLANs on interface %s of type %s",
nm_device_get_iface(parent),
nm_device_get_type_desc(parent));
return FALSE;
}
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
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
vlan_id = nm_setting_vlan_get_id(s_vlan);
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
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
r = nm_platform_link_vlan_add(nm_device_get_platform(device),
iface,
parent_ifindex,
vlan_id,
nm_setting_vlan_get_flags(s_vlan),
out_plink);
if (r < 0) {
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_set_error(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_CREATION_FAILED,
"Failed to create VLAN interface '%s' for '%s': %s",
iface,
nm_connection_get_id(connection),
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
nm_strerror(r));
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
return FALSE;
}
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
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
nm_device_parent_set_ifindex(device, parent_ifindex);
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
if (vlan_id != priv->vlan_id) {
priv->vlan_id = vlan_id;
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
_notify((NMDeviceVlan *) device, PROP_VLAN_ID);
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01: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
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
return TRUE;
}
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
static void
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
unrealize_notify(NMDevice *device)
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
{
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDeviceVlan * self = NM_DEVICE_VLAN(device);
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE(self);
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
NM_DEVICE_CLASS(nm_device_vlan_parent_class)->unrealize_notify(device);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (priv->vlan_id != 0) {
priv->vlan_id = 0;
_notify(self, PROP_VLAN_ID);
}
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
core: rearrange some VLAN code and clean up dispose() Move parent-related stuff before its callers and clean up dispose so that we no longer need priv->disposed.
2014-10-06 17:17:54 -05:00
static NMDeviceCapabilities
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
get_generic_capabilities(NMDevice *device)
core: rearrange some VLAN code and clean up dispose() Move parent-related stuff before its callers and clean up dispose so that we no longer need priv->disposed.
2014-10-06 17:17:54 -05:00
{
/* We assume VLAN interfaces always support carrier detect */
return NM_DEVICE_CAP_CARRIER_DETECT | NM_DEVICE_CAP_IS_SOFTWARE;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: rearrange some VLAN code and clean up dispose() Move parent-related stuff before its callers and clean up dispose so that we no longer need priv->disposed.
2014-10-06 17:17:54 -05:00
static gboolean
is_available(NMDevice *device, NMDeviceCheckDevAvailableFlags flags)
{
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (!nm_device_parent_get_device(device))
core: rearrange some VLAN code and clean up dispose() Move parent-related stuff before its callers and clean up dispose so that we no longer need priv->disposed.
2014-10-06 17:17:54 -05:00
return FALSE;
return NM_DEVICE_CLASS(nm_device_vlan_parent_class)->is_available(device, flags);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
trivial: move code
2015-04-29 10:06:51 +02:00
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
static gboolean
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
check_connection_compatible(NMDevice *device, NMConnection *connection, GError **error)
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
{
all: drop explicit casts from _GET_PRIVATE() macro calls The _GET_PRIVATE() macros are all implemented based on _NM_GET_PRIVATE(). That macro tries to be more type safe and uses _Generic() to do the right thing. Explicitly casting is not only unnecessary, it defeats these (static) type checks. Don't do that.
2020-02-14 10:50:25 +01:00
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE(device);
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
NMSettingVlan * s_vlan;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
const char * parent;
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
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (!NM_DEVICE_CLASS(nm_device_vlan_parent_class)
->check_connection_compatible(device, connection, error))
core: make nm_device_check_connection_compatible() check interface-name If an NMConnection specifies an interface-name, it is only compatible with a device with the same iface. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-07 07:44:36 -05:00
return FALSE;
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
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
if (nm_device_is_real(device)) {
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
s_vlan = nm_connection_get_setting_vlan(connection);
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
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (nm_setting_vlan_get_id(s_vlan) != priv->vlan_id) {
nm_utils_error_set_literal(error,
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"vlan id setting mismatches");
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
return FALSE;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +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
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
/* Check parent interface; could be an interface name or a UUID */
parent = nm_setting_vlan_get_parent(s_vlan);
if (parent) {
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (!nm_device_match_parent(device, parent)) {
nm_utils_error_set_literal(error,
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"vlan parent setting differs");
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
return FALSE;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
}
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
} else {
/* Parent could be a MAC address in an NMSettingWired */
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
if (!nm_device_match_parent_hwaddr(device, connection, TRUE)) {
nm_utils_error_set_literal(error,
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
"vlan parent mac setting differs");
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
return FALSE;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
}
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
}
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06: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
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
return TRUE;
}
vlan: make connection available if the device is not real Otherwise NMDevice would do and always fail a carrier check, making it impossible to ever manually activate a vlan connection.
2016-01-04 11:57:22 +01:00
static gboolean
check_connection_available(NMDevice * device,
NMConnection * connection,
NMDeviceCheckConAvailableFlags flags,
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
const char * specific_object,
GError ** error)
vlan: make connection available if the device is not real Otherwise NMDevice would do and always fail a carrier check, making it impossible to ever manually activate a vlan connection.
2016-01-04 11:57:22 +01:00
{
if (!nm_device_is_real(device))
return TRUE;
core: give better error reason why device is unavailable The error reason is still unused.
2018-06-27 16:21:43 +02:00
return NM_DEVICE_CLASS(nm_device_vlan_parent_class)
->check_connection_available(device, connection, flags, specific_object, error);
vlan: make connection available if the device is not real Otherwise NMDevice would do and always fail a carrier check, making it impossible to ever manually activate a vlan connection.
2016-01-04 11:57:22 +01:00
}
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
static gboolean
core: remove "real_" prefix from method implementation names The idea was copied from gtk, but it's only used there in cases where the method's wrapper function and default implementation would otherwise have the same name, which never happens in NM because our method implementations aren't prefixed with the type name, so it's just noise here.
2012-09-27 12:12:15 -04:00
complete_connection(NMDevice * device,
NMConnection * connection,
const char * specific_object,
core: avoid clone of all-connections list for nm_utils_complete_generic() NMSettings exposes a cached list of all connection. We don't need to clone it. Note that this is not save against concurrent modification, meaning, add/remove of connections in NMSettings will invalidate the list. However, it wasn't save against that previously either, because altough we cloned the container (GSList), we didn't take an additional reference to the elements. This is purely a performance optimization, we don't need to clone the list. Also, since the original list is of type "NMConnection *const*", use that type insistently, instead of dependent API requiring GSList. IMO, GSList is anyway not a very nice API for many use cases because it requires an additional slice allocation for each element. It's slower, and often less convenient to use.
2018-03-14 08:57:42 +01:00
NMConnection *const *existing_connections,
core: remove "real_" prefix from method implementation names The idea was copied from gtk, but it's only used there in cases where the method's wrapper function and default implementation would otherwise have the same name, which never happens in NM because our method implementations aren't prefixed with the type name, so it's just noise here.
2012-09-27 12:12:15 -04:00
GError ** error)
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
{
NMSettingVlan *s_vlan;
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
device: don't use platform singleton getter in device subclasses Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get the platform singleton instance. For one, this is a step towards supporting namespaces, where we need to use different NMNetns/NMPlatform instances depending on in which namespace the device lives. Also, we should reduce our use of singletons. They are difficult to coordinate on shutdown. Instead there should be a clear order of dependencies, expressed by owning a reference to those singelton instances. We already own a reference to the platform singelton, so use it and avoid NM_PLATFORM_GET. (cherry picked from commit 94d9ee129d85ff926a10de78fedcc6b57cdcdb19)
2017-04-18 12:09:02 +02:00
nm_utils_complete_generic(nm_device_get_platform(device),
utils: inject platform into nm_utils_complete_generic()
2016-03-08 13:57:20 +01:00
connection,
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
NM_SETTING_VLAN_SETTING_NAME,
existing_connections,
NULL,
core: refactor nm_utils_complete_generic() not to use a dynamic format string For NMDeviceWifi and NMDeviceWimax, the printf format string for nm_utils_complete_generic() was created based on ssid/nsp. Since these input strings are untrusted, this is a serious bug. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-25 16:21:59 +02:00
_("VLAN connection"),
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
NULL,
core: abstract out the duplicated default-ifname-generating code NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the same code to generate a default interface name. Move it into nm_utils_complete_generic().
2014-08-05 17:11:57 -04:00
NULL,
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
s_vlan = nm_connection_get_setting_vlan(connection);
if (!s_vlan) {
devices: drop device-type-specific error domains Most NMDevice types defined their own error domain but then never used it. A few did use their errors, but some of those errors are redundant with NMDeviceError, and others can be added to it.
2014-09-22 12:28:06 -04:00
g_set_error_literal(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INVALID_CONNECTION,
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
"A 'vlan' setting is required.");
return FALSE;
}
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
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
/* If there's no VLAN interface, no parent, and no hardware address in the
* settings, then there's not enough information to complete the setting.
*/
all: standardize on NMSettingWired:mac-address for all VLANs Currently, ethernet-based VLANs can specify the hardware address of the parent device (and, in theory, the cloned hardware address and MTU of the VLAN device) by using an NMSettingWired in addition to the NMSettingVlan. The theory was that non-ethernet-based VLANs, when we eventually supported them, would likewise use the setting type corresponding to their parent device. However, this turns out to be both complicated (the settings plugins and connection editor would have a hard-to-impossible time figuring out which setting type to use in some cases) and incorrect (for most L2 settings [eg, BSSID, bond mode, etc], the VLAN can't have its own values separate from the parent device). What we should have done was just have :mac-address, :cloned-mac-address, and :mtu properties on NMSettingVlan. However, at this point, for backward-compatibility, we will just stick with using a combination of NMSettingVlan and NMSettingWired, but we will use NMSettingWired regardless of the underlying hardware type.
2013-09-09 09:40:40 -04:00
if (!nm_setting_vlan_get_parent(s_vlan)
core/trival: rename nm_device_match_hwaddr() function to nm_device_match_parent_hwaddr() This name is better, because it compares the MAC address of the device's parent.
2018-06-27 22:48:50 +02:00
&& !nm_device_match_parent_hwaddr(device, connection, TRUE)) {
devices: drop device-type-specific error domains Most NMDevice types defined their own error domain but then never used it. A few did use their errors, but some of those errors are redundant with NMDeviceError, and others can be added to it.
2014-09-22 12:28:06 -04:00
g_set_error_literal(
error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INVALID_CONNECTION,
all: standardize on NMSettingWired:mac-address for all VLANs Currently, ethernet-based VLANs can specify the hardware address of the parent device (and, in theory, the cloned hardware address and MTU of the VLAN device) by using an NMSettingWired in addition to the NMSettingVlan. The theory was that non-ethernet-based VLANs, when we eventually supported them, would likewise use the setting type corresponding to their parent device. However, this turns out to be both complicated (the settings plugins and connection editor would have a hard-to-impossible time figuring out which setting type to use in some cases) and incorrect (for most L2 settings [eg, BSSID, bond mode, etc], the VLAN can't have its own values separate from the parent device). What we should have done was just have :mac-address, :cloned-mac-address, and :mtu properties on NMSettingVlan. However, at this point, for backward-compatibility, we will just stick with using a combination of NMSettingVlan and NMSettingWired, but we will use NMSettingWired regardless of the underlying hardware type.
2013-09-09 09:40:40 -04:00
"The 'vlan' setting had no interface name, parent, or hardware address.");
return FALSE;
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06: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
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
return TRUE;
}
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
static void
update_connection(NMDevice *device, NMConnection *connection)
{
shared: rework _NM_GET_PRIVATE() to use _Generic() _NM_GET_PRIVATE() used typeof() to propagate constness of the @self pointer. However, that means, it could only be used with a self pointer of the exact type. That means, you explicitly had to cast from (GObject *) or from (void *). The requirement is cumbersome, and often led us to either create @self pointer we didn't need: NMDeviceVlan *self = NM_DEVICE_VLAN (device); NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE (self); or casting: NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDevice *) device); In both cases we forcefully cast the source variable, loosing help from the compiler to detect a bug. For "nm-linux-platform.c", instead we commonly have a pointer of type NMPlatform. Hence, we always forcefully cast the type via _NM_GET_PRIVATE_VOID(). Rework the macro to use _Generic(). If compiler supports _Generic(), then we will get all compile time checks as desired. If the compiler doesn't support _Generic(), it will still work. You don't get the compile-time checking of course, but you'd notice that something is wrong once you build with a suitable compiler.
2017-11-09 10:05:00 +01:00
NMDeviceVlanPrivate * priv = NM_DEVICE_VLAN_GET_PRIVATE(device);
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
NMSettingVlan * s_vlan = nm_connection_get_setting_vlan(connection);
int ifindex = nm_device_get_ifindex(device);
platform: implement vlan properties as lnk data
2015-10-12 13:44:44 +02:00
const NMPlatformLink *plink;
vlan: handle vlan flags, ingress and egress map in NMDeviceVlan In update_connection(), pickup the configuration of the vlan interface from platform and create the proper NMSettingVlan setting. And during stage1, configure the flags of the device. Also, change all the ingress/egress mappings at once instead of having a netlink request for each mapping. Also, ensure we *clear* all other mappings so that only those are set, that were configured (done by the *gress_reset_all argument).
2015-10-30 11:02:44 +01:00
const NMPObject * polnk;
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
guint vlan_id;
guint vlan_flags;
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
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
if (!s_vlan) {
s_vlan = (NMSettingVlan *) nm_setting_vlan_new();
nm_connection_add_setting(connection, (NMSetting *) s_vlan);
}
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
device: don't use platform singleton getter in device subclasses Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get the platform singleton instance. For one, this is a step towards supporting namespaces, where we need to use different NMNetns/NMPlatform instances depending on in which namespace the device lives. Also, we should reduce our use of singletons. They are difficult to coordinate on shutdown. Instead there should be a clear order of dependencies, expressed by owning a reference to those singelton instances. We already own a reference to the platform singelton, so use it and avoid NM_PLATFORM_GET. (cherry picked from commit 94d9ee129d85ff926a10de78fedcc6b57cdcdb19)
2017-04-18 12:09:02 +02:00
polnk = nm_platform_link_get_lnk(nm_device_get_platform(device),
ifindex,
NM_LINK_TYPE_VLAN,
&plink);
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
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
if (polnk)
vlan_id = polnk->lnk_vlan.id;
platform: handle parent interfaces in other netns The parent of a link (IFLA_LINK) can be in another network namespace and thus invisible to NM. This requires the netlink attribute IFLA_LINK_NETNSID which is supported by recent versions of kernel and libnl. In this case, set the parent field to NM_PLATFORM_LINK_OTHER_NETNS and properly handle this special case.
2015-08-17 17:48:37 +02:00
else
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
vlan_id = priv->vlan_id;
if (vlan_id != nm_setting_vlan_get_id(s_vlan))
g_object_set(s_vlan, NM_SETTING_VLAN_ID, vlan_id, NULL);
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
device: refactor setting parent in device's update_connection() Add a helper function nm_device_parent_find_for_connection() to unify implementations of setting the parent in update_connection(). There is some change in behavior, in particular for nm-device-vlan.c, which no longer compares the link information from platform. But update_connection() is anyway a questionable concept, only used for external assumed connection (which itself, is questionable). Meaning, update_connection() is a hack not science, and it's not at all clear what the correct behavior is. Also, note how vlan's implementation differs from all others. Why? Should we always resort to also check the information from platform? Either way, one of the two approaches should be used consistently and nm_device_parent_find_for_connection() opts to not consult platform cache.
2018-08-17 22:18:17 +02:00
g_object_set(s_vlan,
NM_SETTING_VLAN_PARENT,
nm_device_parent_find_for_connection(device, nm_setting_vlan_get_parent(s_vlan)),
NULL);
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
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
if (polnk)
vlan_flags = polnk->lnk_vlan.flags;
else
vlan_flags = NM_VLAN_FLAG_REORDER_HEADERS;
if (vlan_flags != nm_setting_vlan_get_flags(s_vlan))
g_object_set(s_vlan, NM_SETTING_VLAN_FLAGS, (NMVlanFlags) vlan_flags, NULL);
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
device/vlan: refactor handling platform properties for NMDeviceVlan Extract a function update_properties() similar to other device implementations. It reads the device specific data from platform and raises property-changed notifications. update_properties() is now called by realize_start_notify(). NMDeviceVlan:realize() -- which previously implemented something like update_properties() -- now does nothing. Note that previously realize() might have failed, but this is different from other device implementations and it was unclear what a failure really meant. Ok, it might fail because the link was not found in the platform cache. But other implementations don't check that either, so why vlan? And how to handle that properly anyway? Therefore realize()'s implementation is no longer needed because nm_device_realize() already calls realize_start_setup(), which calls realize_start_notify() and update_properties(). update_connection() no longer refreshes the device properties. Instead it only modifies the passed-in NMConnection. It's a bit ugly that update_connection() uses both cached properties from NMDeviceVlan (vlan_id) and platform properties (xgress maps). Also, update_connection() doesn't return early on error but continues trying to update the NMConnection. The reason is that update_connection() cannot return a failure status.
2016-01-10 14:31:10 +01:00
if (polnk) {
_nm_setting_vlan_set_priorities(s_vlan,
NM_VLAN_INGRESS_MAP,
polnk->_lnk_vlan.ingress_qos_map,
polnk->_lnk_vlan.n_ingress_qos_map);
_nm_setting_vlan_set_priorities(s_vlan,
NM_VLAN_EGRESS_MAP,
polnk->_lnk_vlan.egress_qos_map,
polnk->_lnk_vlan.n_egress_qos_map);
} else {
_nm_setting_vlan_set_priorities(s_vlan, NM_VLAN_INGRESS_MAP, NULL, 0);
_nm_setting_vlan_set_priorities(s_vlan, NM_VLAN_EGRESS_MAP, NULL, 0);
}
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
}
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04:00
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
act_stage1_prepare(NMDevice *device, NMDeviceStateReason *out_failure_reason)
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04:00
{
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDevice * parent_device;
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04:00
NMSettingVlan *s_vlan;
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
device/vlan: update hw address also during prepare phase The hardware address of a VLAN must be kept aligned with the one of its parent device, and we already used a signal in NMDeviceVlan to catch changes in parent address and update the VLAN device accordingly. But this didn't work in all cases because the change might happen after the VLAN gets created but before we register the signal, so it is necessary to add further checks to enforce the alignment during the device activation. https://bugzilla.redhat.com/show_bug.cgi?id=1325752
2016-04-12 10:41:20 +02:00
/* Change MAC address to parent's one if needed */
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_device = nm_device_parent_get_device(device);
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
if (parent_device) {
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_hwaddr_maybe_changed(parent_device, NULL, device);
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
parent_mtu_maybe_changed(parent_device, NULL, device);
}
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
core: don't cast return value of nm_device_get_applied_setting()
2018-10-22 13:06:27 +02:00
s_vlan = nm_device_get_applied_setting(device, NM_TYPE_SETTING_VLAN);
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04:00
if (s_vlan) {
vlan: handle vlan flags, ingress and egress map in NMDeviceVlan In update_connection(), pickup the configuration of the vlan interface from platform and create the proper NMSettingVlan setting. And during stage1, configure the flags of the device. Also, change all the ingress/egress mappings at once instead of having a netlink request for each mapping. Also, ensure we *clear* all other mappings so that only those are set, that were configured (done by the *gress_reset_all argument).
2015-10-30 11:02:44 +01:00
gs_free NMVlanQosMapping *ingress_map = NULL;
gs_free NMVlanQosMapping *egress_map = NULL;
device: various minor style cleanup
2019-08-22 07:41:34 +02:00
guint n_ingress_map = 0;
guint n_egress_map = 0;
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
vlan: handle vlan flags, ingress and egress map in NMDeviceVlan In update_connection(), pickup the configuration of the vlan interface from platform and create the proper NMSettingVlan setting. And during stage1, configure the flags of the device. Also, change all the ingress/egress mappings at once instead of having a netlink request for each mapping. Also, ensure we *clear* all other mappings so that only those are set, that were configured (done by the *gress_reset_all argument).
2015-10-30 11:02:44 +01:00
_nm_setting_vlan_get_priorities(s_vlan, NM_VLAN_INGRESS_MAP, &ingress_map, &n_ingress_map);
_nm_setting_vlan_get_priorities(s_vlan, NM_VLAN_EGRESS_MAP, &egress_map, &n_egress_map);
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
device: don't use platform singleton getter in device subclasses Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get the platform singleton instance. For one, this is a step towards supporting namespaces, where we need to use different NMNetns/NMPlatform instances depending on in which namespace the device lives. Also, we should reduce our use of singletons. They are difficult to coordinate on shutdown. Instead there should be a clear order of dependencies, expressed by owning a reference to those singelton instances. We already own a reference to the platform singelton, so use it and avoid NM_PLATFORM_GET. (cherry picked from commit 94d9ee129d85ff926a10de78fedcc6b57cdcdb19)
2017-04-18 12:09:02 +02:00
nm_platform_link_vlan_change(nm_device_get_platform(device),
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
nm_device_get_ifindex(device),
vlan: handle vlan flags, ingress and egress map in NMDeviceVlan In update_connection(), pickup the configuration of the vlan interface from platform and create the proper NMSettingVlan setting. And during stage1, configure the flags of the device. Also, change all the ingress/egress mappings at once instead of having a netlink request for each mapping. Also, ensure we *clear* all other mappings so that only those are set, that were configured (done by the *gress_reset_all argument).
2015-10-30 11:02:44 +01:00
NM_VLAN_FLAGS_ALL,
nm_setting_vlan_get_flags(s_vlan),
TRUE,
ingress_map,
n_ingress_map,
TRUE,
egress_map,
n_egress_map);
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04: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
device: various minor style cleanup
2019-08-22 07:41:34 +02:00
return NM_ACT_STAGE_RETURN_SUCCESS;
core: set VLAN ingress/egress maps at activation time Rather than setting the VLAN maps when the device is created, set them at activation time, which is more in line with how other device types work. Like the old code, this doesn't attempt to reset any existing ingress/egress mappings on the device.
2013-09-03 14:03:52 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
static void
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
{
shared: rework _NM_GET_PRIVATE() to use _Generic() _NM_GET_PRIVATE() used typeof() to propagate constness of the @self pointer. However, that means, it could only be used with a self pointer of the exact type. That means, you explicitly had to cast from (GObject *) or from (void *). The requirement is cumbersome, and often led us to either create @self pointer we didn't need: NMDeviceVlan *self = NM_DEVICE_VLAN (device); NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE (self); or casting: NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDevice *) device); In both cases we forcefully cast the source variable, loosing help from the compiler to detect a bug. For "nm-linux-platform.c", instead we commonly have a pointer of type NMPlatform. Hence, we always forcefully cast the type via _NM_GET_PRIVATE_VOID(). Rework the macro to use _Generic(). If compiler supports _Generic(), then we will get all compile time checks as desired. If the compiler doesn't support _Generic(), it will still work. You don't get the compile-time checking of course, but you'd notice that something is wrong once you build with a suitable compiler.
2017-11-09 10:05:00 +01:00
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE(object);
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
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
switch (prop_id) {
case PROP_VLAN_ID:
g_value_set_uint(value, priv->vlan_id);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
break;
}
}
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
/*****************************************************************************/
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
static void
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
nm_device_vlan_init(NMDeviceVlan *self)
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
{}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static const NMDBusInterfaceInfoExtended interface_info_device_vlan = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT(
NM_DBUS_INTERFACE_DEVICE_VLAN,
.signals = NM_DEFINE_GDBUS_SIGNAL_INFOS(&nm_signal_info_property_changed_legacy, ),
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS(
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L("HwAddress",
"s",
NM_DEVICE_HW_ADDRESS),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L("Carrier", "b", NM_DEVICE_CARRIER),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L("Parent", "o", NM_DEVICE_PARENT),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L("VlanId",
"u",
NM_DEVICE_VLAN_ID), ), ),
.legacy_property_changed = TRUE,
};
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
static void
nm_device_vlan_class_init(NMDeviceVlanClass *klass)
{
GObjectClass * object_class = G_OBJECT_CLASS(klass);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS(klass);
device/trivial: rename parent-class variable in device class constructor The majority of device implementations name their parent-class variable "device_class". That also makes more sense as it is more consistant. E.g. "parent" sounds like it's the direct parent, but that is not the crucial point here. The crucial point at this place, is that we access the NMDeviceClass typed pointer. Rename.
2018-07-10 07:45:35 +02:00
NMDeviceClass * device_class = NM_DEVICE_CLASS(klass);
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
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
object_class->get_property = get_property;
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
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS(&interface_info_device_vlan);
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
device: replace NM_DEVICE_CLASS_DECLARE_TYPES() macro by explicit initialization It seems to me the NM_DEVICE_CLASS_DECLARE_TYPES() macro confuses more than helping. Let's explicitly initialize the two fields, albeit with another helper macro NM_DEVICE_DEFINE_LINK_TYPES() to get the list of link-types right. For consistency, also leave nop-lines like device_class->connection_type_supported = NULL; device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (); because all NMDevice class init methods should have this same boiler plate code and to make it explicit that this is intended. And there are only 3 occurences where this actually comes into play.
2018-07-10 09:26:42 +02:00
device_class->connection_type_supported = NM_SETTING_VLAN_SETTING_NAME;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
device_class->connection_type_check_compatible = NM_SETTING_VLAN_SETTING_NAME;
device: replace NM_DEVICE_CLASS_DECLARE_TYPES() macro by explicit initialization It seems to me the NM_DEVICE_CLASS_DECLARE_TYPES() macro confuses more than helping. Let's explicitly initialize the two fields, albeit with another helper macro NM_DEVICE_DEFINE_LINK_TYPES() to get the list of link-types right. For consistency, also leave nop-lines like device_class->connection_type_supported = NULL; device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (); because all NMDevice class init methods should have this same boiler plate code and to make it explicit that this is intended. And there are only 3 occurences where this actually comes into play.
2018-07-10 09:26:42 +02:00
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES(NM_LINK_TYPE_VLAN);
device: introduce generic function to inherit MTU from parent Introduce a generic function to set a MTU based on parent's one. Also define a device-specific @mtu_parent_delta value that specifies the difference from parent MTU that should be set by default. For VLAN it is zero but other interface types (for example MACsec) require a positive value due to encapsulation overhead.
2019-09-12 17:29:49 +02:00
device_class->mtu_parent_delta = 0; /* VLANs can have the same MTU of parent */
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
device/trivial: rename parent-class variable in device class constructor The majority of device implementations name their parent-class variable "device_class". That also makes more sense as it is more consistant. E.g. "parent" sounds like it's the direct parent, but that is not the crucial point here. The crucial point at this place, is that we access the NMDeviceClass typed pointer. Rename.
2018-07-10 07:45:35 +02:00
device_class->create_and_realize = create_and_realize;
device_class->link_changed = link_changed;
device_class->unrealize_notify = unrealize_notify;
device_class->get_generic_capabilities = get_generic_capabilities;
device: let NMDevice set hardware address instead of act_stage1_prepare()
2019-08-22 09:57:55 +02:00
device_class->act_stage1_prepare_set_hwaddr_ethernet = TRUE;
device/trivial: rename parent-class variable in device class constructor The majority of device implementations name their parent-class variable "device_class". That also makes more sense as it is more consistant. E.g. "parent" sounds like it's the direct parent, but that is not the crucial point here. The crucial point at this place, is that we access the NMDeviceClass typed pointer. Rename.
2018-07-10 07:45:35 +02:00
device_class->act_stage1_prepare = act_stage1_prepare;
device: introduce generic function to inherit MTU from parent Introduce a generic function to set a MTU based on parent's one. Also define a device-specific @mtu_parent_delta value that specifies the difference from parent MTU that should be set by default. For VLAN it is zero but other interface types (for example MACsec) require a positive value due to encapsulation overhead.
2019-09-12 17:29:49 +02:00
device_class->get_configured_mtu = nm_device_get_configured_mtu_wired_parent;
device/trivial: rename parent-class variable in device class constructor The majority of device implementations name their parent-class variable "device_class". That also makes more sense as it is more consistant. E.g. "parent" sounds like it's the direct parent, but that is not the crucial point here. The crucial point at this place, is that we access the NMDeviceClass typed pointer. Rename.
2018-07-10 07:45:35 +02:00
device_class->is_available = is_available;
device_class->parent_changed_notify = parent_changed_notify;
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
device/trivial: rename parent-class variable in device class constructor The majority of device implementations name their parent-class variable "device_class". That also makes more sense as it is more consistant. E.g. "parent" sounds like it's the direct parent, but that is not the crucial point here. The crucial point at this place, is that we access the NMDeviceClass typed pointer. Rename.
2018-07-10 07:45:35 +02:00
device_class->check_connection_compatible = check_connection_compatible;
device_class->check_connection_available = check_connection_available;
device_class->complete_connection = complete_connection;
device_class->update_connection = update_connection;
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
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
obj_properties[PROP_VLAN_ID] = g_param_spec_uint(NM_DEVICE_VLAN_ID,
"",
"",
0,
4095,
0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
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
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
core: convert VLAN interfaces to a device subclass Many different interface types can support VLANs, including Infiniband, WiFi, etc. So we have to create a new device class for them instead of keeping the support in NMDeviceEthernet.
2012-02-22 23:59:50 -06:00
}
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
device: rename internal device factories Instead of NMBondFactory, call it NMBondDeviceFactory.
2016-10-07 17:00:59 +02:00
#define NM_TYPE_VLAN_DEVICE_FACTORY (nm_vlan_device_factory_get_type())
#define NM_VLAN_DEVICE_FACTORY(obj) \
(G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_VLAN_DEVICE_FACTORY, NMVlanDeviceFactory))
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
static NMDevice *
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
create_device(NMDeviceFactory * factory,
const char * iface,
device: pass NMPlatformLink instance as const pointer
2016-01-10 15:13:20 +01:00
const NMPlatformLink *plink,
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
NMConnection * connection,
gboolean * out_ignore)
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
{
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
return (NMDevice *) g_object_new(NM_TYPE_DEVICE_VLAN,
NM_DEVICE_IFACE,
iface,
NM_DEVICE_DRIVER,
"8021q",
NM_DEVICE_TYPE_DESC,
"VLAN",
NM_DEVICE_DEVICE_TYPE,
NM_DEVICE_TYPE_VLAN,
device: set link type from all factories This is, in particular, important for devices that support multiple link types which can not be changed once the platform device exists.
2015-12-08 14:51:12 +01:00
NM_DEVICE_LINK_TYPE,
NM_LINK_TYPE_VLAN,
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
NULL);
vlan: port to internal device factory
2014-09-08 10:24:11 -05:00
}
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
static const char *
get_connection_parent(NMDeviceFactory *factory, NMConnection *connection)
{
NMSettingVlan * s_vlan;
NMSettingWired *s_wired;
const char * parent = NULL;
g_return_val_if_fail(nm_connection_is_type(connection, NM_SETTING_VLAN_SETTING_NAME), NULL);
s_vlan = nm_connection_get_setting_vlan(connection);
g_assert(s_vlan);
parent = nm_setting_vlan_get_parent(s_vlan);
if (parent)
return parent;
/* Try the hardware address from the VLAN connection's hardware setting */
s_wired = nm_connection_get_setting_wired(connection);
if (s_wired)
return nm_setting_wired_get_mac_address(s_wired);
return NULL;
}
static char *
device-factory/trivial: rename get_virtual_iface_name() to get_connection_iface()
2016-02-17 15:11:02 +01:00
get_connection_iface(NMDeviceFactory *factory, NMConnection *connection, const char *parent_iface)
core: move virtual interface name handling into device plugins Instead of having a bunch of logic in the Manager for determining the VLAN and Infiniband virtual interface names, move the type-specific logic into the plugins themselves.
2014-09-18 17:50:47 -05:00
{
const char * ifname;
NMSettingVlan *s_vlan;
g_return_val_if_fail(nm_connection_is_type(connection, NM_SETTING_VLAN_SETTING_NAME), NULL);
s_vlan = nm_connection_get_setting_vlan(connection);
g_assert(s_vlan);
if (!parent_iface)
return NULL;
ifname = nm_connection_get_interface_name(connection);
if (ifname)
return g_strdup(ifname);
/* If the connection doesn't specify the interface name for the VLAN
* device, we create one for it using the VLAN ID and the parent
* interface's name.
*/
return nm_utils_new_vlan_name(parent_iface, nm_setting_vlan_get_id(s_vlan));
}
core: let device plugins advertise supported link and setting types Instead of looping over all plugins and asking each plugin whether it can handle a link or a connection, have them advertise the link and connection types they support, and use that when creating new devices.
2014-09-17 14:17:30 -05:00
NM_DEVICE_FACTORY_DEFINE_INTERNAL(
VLAN,
Vlan,
vlan,
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES(NM_LINK_TYPE_VLAN)
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES(NM_SETTING_VLAN_SETTING_NAME),
device: make NMDeviceFactory a class instead of an interface An interface would make sense to allow the actual device-factory to inherit from another type. However, glib interfaces make code much harder to follow and less efficient. The device factory shall be a very simple type with meta data about supported device types and the ability to create device instances. There is no need to make this an interface implementation, instead just let the factories inherit from NM_TYPE_DEVICE_FACTORY directly.
2016-10-07 16:05:43 +02:00
factory_class->create_device = create_device;
factory_class->get_connection_parent = get_connection_parent;
factory_class->get_connection_iface = get_connection_iface;);
Reference in a new issue Copy permalink