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

733 lines
23 KiB
C
Raw Normal View History

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
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Copyright 2011 - 2012 Red Hat, Inc.
*/
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
all: rename the introspection data to use the interface paths in names This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-23 13:14:08 +01:00
#include "introspection/org.freedesktop.NetworkManager.Device.Vlan.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
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"
_LOG_DECLARE_SELF(NMDeviceVlan);
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/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)
#define NM_DEVICE_VLAN_GET_PRIVATE(self) _NM_GET_PRIVATE (self, NMDeviceVlan, NM_IS_DEVICE_VLAN)
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/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;
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;
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
connection = nm_device_get_applied_connection ((NMDevice *) self);
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;
/* Update the VLAN MAC only if configuration does not specify one */
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
if (nm_device_hw_addr_is_explict ((NMDevice *) self))
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;
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
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
old_mac = nm_device_get_hw_address ((NMDevice *) self);
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;
_LOGD (LOGD_VLAN, "parent hardware address changed to %s%s%s",
NM_PRINT_FMT_QUOTE_STRING (new_mac));
if (new_mac) {
device: add @set_permanent argument to nm_device_hw_addr_set() In a later commit the function will be used to restore a MAC address without changing its type.
2016-10-25 16:41:42 +02:00
nm_device_hw_addr_set ((NMDevice *) self, new_mac, "vlan-parent", TRUE);
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: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
nm_device_reactivate_ip6_config (NM_DEVICE (self), s_ip6, s_ip6, FALSE);
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);
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
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);
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
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);
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
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
}
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
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
priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDeviceVlan *) 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
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 ( plnk
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
&& 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)
{
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
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDeviceVlan *) 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;
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
NMPlatformError plerr;
s_vlan = nm_connection_get_setting_vlan (connection);
g_assert (s_vlan);
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) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"VLAN devices can not be created without a parent interface");
return FALSE;
}
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;
}
parent_ifindex = nm_device_get_ifindex (parent);
g_warn_if_fail (parent_ifindex > 0);
vlan_id = nm_setting_vlan_get_id (s_vlan);
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
plerr = nm_platform_link_vlan_add (nm_device_get_platform (device),
platform/trivial: rename link related functions Link related functions should have a "nm_platform_link" prefix. Rename. Naming is a subjective matter and one might argue that omitting the "link" part from the name is shorter and even preferred. However, I think functions related to links should have a common prefix as the underlyings are strongly related.
2015-12-09 16:14:49 +01:00
iface,
parent_ifindex,
vlan_id,
nm_setting_vlan_get_flags (s_vlan),
out_plink);
core: reject existing links when trying to add a link via platform When we decide to add a new link, we alredy checked that no such link exists (ignoring race conditions). It is wrong to accept a EXITS failure when adding the link. There is no guarantee that the existing link has all the same properties as the one we intend to add. More importantly, this link was added externally outside of NetworkManager and it should not be taken over. Just treat EXISTS as a failure as any other.
2016-01-25 13:03:51 +01:00
if (plerr != NM_PLATFORM_ERROR_SUCCESS) {
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),
nm_platform_error_to_string (plerr));
return FALSE;
}
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
}
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: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
match_parent (NMDeviceVlan *self, const char *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
{
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDevice *parent_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
g_return_val_if_fail (parent != NULL, FALSE);
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 (NM_DEVICE (self));
if (!parent_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
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
if (nm_utils_is_uuid (parent)) {
NMActRequest *parent_req;
NMConnection *parent_connection;
/* If the parent is a UUID, the connection matches if our parent
* device has that connection activated.
*/
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_req = nm_device_get_act_request (parent_device);
core: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
if (!parent_req)
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: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
parent_connection = nm_active_connection_get_applied_connection (NM_ACTIVE_CONNECTION (parent_req));
core: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
if (!parent_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
return FALSE;
core: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
if (g_strcmp0 (parent, nm_connection_get_uuid (parent_connection)) != 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
return FALSE;
} else {
/* interface name */
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (g_strcmp0 (parent, nm_device_get_ip_iface (parent_device)) != 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
return FALSE;
}
return TRUE;
}
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
static gboolean
match_hwaddr (NMDevice *device, NMConnection *connection, gboolean fail_if_no_hwaddr)
{
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
NMSettingWired *s_wired;
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDevice *parent_device;
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
const char *setting_mac;
const char *parent_mac;
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
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
s_wired = nm_connection_get_setting_wired (connection);
if (!s_wired)
return !fail_if_no_hwaddr;
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
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
setting_mac = nm_setting_wired_get_mac_address (s_wired);
if (!setting_mac)
return !fail_if_no_hwaddr;
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
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);
if (!parent_device)
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
return !fail_if_no_hwaddr;
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
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_mac = nm_device_get_permanent_hw_address (parent_device);
device: fix matching MAC address for VLAN and MACVLAN devices VLAN and MACVLAN devices consider an ethernet.mac-address setting to find the parent device. This setting shall be the permanent MAC address of the device, not the current.
2016-06-15 13:43:34 +02:00
return parent_mac && nm_utils_hwaddr_matches (setting_mac, -1, parent_mac, -1);
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
}
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 unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
check_connection_compatible (NMDevice *device, NMConnection *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
{
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
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDeviceVlan *) 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;
device: remove interface name checks from all classes Generic check_connection_compatible() already does the check.
2016-02-16 16:50:00 +01:00
const char *parent = 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
core: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
if (!NM_DEVICE_CLASS (nm_device_vlan_parent_class)->check_connection_compatible (device, connection))
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;
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);
core: remove unused 'error' argument to check_connection_compatible() Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
2014-05-30 13:44:53 -05:00
if (!s_vlan)
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: 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
/* Before the device is realized some properties will not be set */
if (nm_device_is_real (device)) {
if (nm_setting_vlan_get_id (s_vlan) != priv->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
return FALSE;
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) {
if (!match_parent (NM_DEVICE_VLAN (device), parent))
return FALSE;
} else {
/* Parent could be a MAC address in an NMSettingWired */
if (!match_hwaddr (device, connection, TRUE))
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
}
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,
const char *specific_object)
{
if (!nm_device_is_real (device))
return TRUE;
return NM_DEVICE_CLASS (nm_device_vlan_parent_class)->check_connection_available (device, connection, flags, specific_object);
}
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,
const GSList *existing_connections,
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;
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"),
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);
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;
}
/* 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)
&& !match_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
}
return TRUE;
}
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
static void
update_connection (NMDevice *device, NMConnection *connection)
{
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
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDeviceVlan *) 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);
const char *setting_parent, *new_parent;
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: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
NMDevice *parent_device;
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;
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
if (!s_vlan) {
s_vlan = (NMSettingVlan *) nm_setting_vlan_new ();
nm_connection_add_setting (connection, (NMSetting *) s_vlan);
}
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);
coverity: fix various warnings detected with Coverity (fixup) I missed to implement the remarks from https://bugzilla.redhat.com/show_bug.cgi?id=1025894#c4 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-13 18:24:42 +01: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);
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
/* Update parent in the connection; default to parent's interface name */
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);
if ( parent_device
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
&& polnk
&& plink->parent > 0
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
&& nm_device_get_ifindex (parent_device) == plink->parent) {
new_parent = nm_device_get_iface (parent_device);
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
setting_parent = nm_setting_vlan_get_parent (s_vlan);
if (setting_parent && nm_utils_is_uuid (setting_parent)) {
NMConnection *parent_connection;
/* Don't change a parent specified by UUID if it's still valid */
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
parent_connection = (NMConnection *) nm_settings_get_connection_by_uuid (nm_device_get_settings (device), setting_parent);
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (parent_connection && nm_device_check_connection_compatible (parent_device, parent_connection))
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
new_parent = NULL;
}
if (new_parent)
g_object_set (s_vlan, NM_SETTING_VLAN_PARENT, new_parent, NULL);
} else
g_object_set (s_vlan, NM_SETTING_VLAN_PARENT, NULL, NULL);
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
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);
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;
NMActStageReturn ret;
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
ret = NM_DEVICE_CLASS (nm_device_vlan_parent_class)->act_stage1_prepare (device, 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
if (ret != NM_ACT_STAGE_RETURN_SUCCESS)
return ret;
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
if (!nm_device_hw_addr_set_cloned (device, nm_device_get_applied_connection (device), FALSE))
device: fail activation on failure to set cloned MAC address When a user want to explicitly spoof the MAC address, a failure to do so should fail activation. For one, failing to do so may be a security problem. In any case, if user asks to configure the interface in a certain way and we fail to do so that shall result in a failure to activate.
2016-06-18 19:14:33 +02:00
return NM_ACT_STAGE_RETURN_FAILURE;
core: implement :mtu and :cloned-mac-address for VLAN
2013-09-08 13:39:03 -04: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);
if (parent_device)
parent_hwaddr_maybe_changed (parent_device, NULL, 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
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
s_vlan = (NMSettingVlan *) 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;
guint n_ingress_map = 0, n_egress_map = 0;
_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);
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
}
return ret;
}
vlan: use parent interface mtu as default After commit 22e8af624285 ("device: set a per-device default MTU on activation") we explicitly set the VLAN MTU to 1500 if not overridden by user settings. This has the advantage that the MTU is set to a predictable value, while before it could have different values depending on when the interface was created (for example, the interface would get a 1500 MTU if created during boot, or would inherit the parent's MTU if activated manually). However, a better default value is the MTU of the parent interface which is in most cases what the user wants. This value was the default before commit 22e8af624285 for manually activated connections. https://bugzilla.redhat.com/show_bug.cgi?id=1414186 (cherry picked from commit 7dde8d81060405c9c8f45be76300cdac7868fba4)
2017-01-18 11:25:38 +01:00
static guint32
get_configured_mtu (NMDevice *self, gboolean *out_is_user_config)
{
guint32 mtu = 0;
int ifindex;
mtu = nm_device_get_configured_mtu_for_wired (self, out_is_user_config);
if (*out_is_user_config)
return mtu;
/* Inherit the MTU from parent device, if any */
ifindex = nm_device_parent_get_ifindex (self);
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
mtu = nm_platform_link_get_mtu (nm_device_get_platform (NM_DEVICE (self)), ifindex);
vlan: use parent interface mtu as default After commit 22e8af624285 ("device: set a per-device default MTU on activation") we explicitly set the VLAN MTU to 1500 if not overridden by user settings. This has the advantage that the MTU is set to a predictable value, while before it could have different values depending on when the interface was created (for example, the interface would get a 1500 MTU if created during boot, or would inherit the parent's MTU if activated manually). However, a better default value is the MTU of the parent interface which is in most cases what the user wants. This value was the default before commit 22e8af624285 for manually activated connections. https://bugzilla.redhat.com/show_bug.cgi?id=1414186 (cherry picked from commit 7dde8d81060405c9c8f45be76300cdac7868fba4)
2017-01-18 11:25:38 +01:00
return mtu ?: NM_DEVICE_DEFAULT_MTU_WIRED;
}
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)
{
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
NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDeviceVlan *) object);
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
{
}
static void
nm_device_vlan_class_init (NMDeviceVlanClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
NMDeviceClass *parent_class = NM_DEVICE_CLASS (klass);
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
NM_DEVICE_CLASS_DECLARE_TYPES (klass, NM_SETTING_VLAN_SETTING_NAME, NM_LINK_TYPE_VLAN)
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +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;
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
parent_class->create_and_realize = create_and_realize;
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
parent_class->link_changed = link_changed;
device/trivial: rename virtual function NMDevice:unrealize() to unrealize_notify()
2016-01-10 15:18:31 +01:00
parent_class->unrealize_notify = unrealize_notify;
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
parent_class->get_generic_capabilities = get_generic_capabilities;
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
parent_class->act_stage1_prepare = act_stage1_prepare;
vlan: use parent interface mtu as default After commit 22e8af624285 ("device: set a per-device default MTU on activation") we explicitly set the VLAN MTU to 1500 if not overridden by user settings. This has the advantage that the MTU is set to a predictable value, while before it could have different values depending on when the interface was created (for example, the interface would get a 1500 MTU if created during boot, or would inherit the parent's MTU if activated manually). However, a better default value is the MTU of the parent interface which is in most cases what the user wants. This value was the default before commit 22e8af624285 for manually activated connections. https://bugzilla.redhat.com/show_bug.cgi?id=1414186 (cherry picked from commit 7dde8d81060405c9c8f45be76300cdac7868fba4)
2017-01-18 11:25:38 +01:00
parent_class->get_configured_mtu = get_configured_mtu;
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
parent_class->is_available = is_available;
device: move tracking of parent device from NMDeviceVlan to NMDevice
2017-01-02 09:57:43 +01:00
parent_class->parent_changed_notify = parent_changed_notify;
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
parent_class->check_connection_compatible = check_connection_compatible;
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
parent_class->check_connection_available = check_connection_available;
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
parent_class->complete_connection = complete_connection;
core: implement update_connection() for VLANs
2013-07-20 21:48:06 +02:00
parent_class->update_connection = update_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
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);
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
vlan: export parent device for VLANs as D-Bus property and use the internal construct-time parent property for VLAN creation.
2014-07-21 12:15:54 +02:00
core: add an NMExportedObject base class Add NMExportedObject, make it the base class of all D-Bus-exported types, and move the nm-properties-changed-signal logic into it. (Also, make NMSettings use the same properties-changed code as everything else, which it was not previously doing, presumably for historical reasons). (This is mostly just shuffling code around at this point, but NMExportedObject will be more important in the gdbus port, since gdbus-codegen doesn't do a very good job of supporting objects that export multiple interfaces [as each NMDevice subclass does, for example], so we will need more glue/helper code in NMExportedObject then.)
2015-04-13 13:31:42 -04:00
nm_exported_object_class_add_interface (NM_EXPORTED_OBJECT_CLASS (klass),
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
NMDBUS_TYPE_DEVICE_VLAN_SKELETON,
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
}
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;
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
);
Reference in a new issue Copy permalink