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

199 lines
6.2 KiB
C
Raw Normal View History

core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
/* 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.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
* Copyright 2017 Red Hat, Inc.
*/
#include "nm-default.h"
#include "nm-device-dummy.h"
#include <stdlib.h>
#include <sys/types.h>
#include "nm-act-request.h"
#include "nm-device-private.h"
#include "nm-ip4-config.h"
#include "platform/nm-platform.h"
#include "nm-device-factory.h"
#include "nm-setting-dummy.h"
#include "nm-core-internal.h"
#include "nm-device-logging.h"
_LOG_DECLARE_SELF(NMDeviceDummy);
/*****************************************************************************/
struct _NMDeviceDummy {
NMDevice parent;
};
struct _NMDeviceDummyClass {
NMDeviceClass parent;
};
G_DEFINE_TYPE (NMDeviceDummy, nm_device_dummy, NM_TYPE_DEVICE)
/*****************************************************************************/
static NMDeviceCapabilities
get_generic_capabilities (NMDevice *dev)
{
return NM_DEVICE_CAP_IS_SOFTWARE;
}
static gboolean
complete_connection (NMDevice *device,
NMConnection *connection,
const char *specific_object,
core: avoid clone of all-connections list for nm_utils_complete_generic() NMSettings exposes a cached list of all connection. We don't need to clone it. Note that this is not save against concurrent modification, meaning, add/remove of connections in NMSettings will invalidate the list. However, it wasn't save against that previously either, because altough we cloned the container (GSList), we didn't take an additional reference to the elements. This is purely a performance optimization, we don't need to clone the list. Also, since the original list is of type "NMConnection *const*", use that type insistently, instead of dependent API requiring GSList. IMO, GSList is anyway not a very nice API for many use cases because it requires an additional slice allocation for each element. It's slower, and often less convenient to use.
2018-03-14 08:57:42 +01:00
NMConnection *const*existing_connections,
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
GError **error)
{
NMSettingDummy *s_dummy;
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),
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
connection,
NM_SETTING_DUMMY_SETTING_NAME,
existing_connections,
NULL,
_("Dummy connection"),
NULL,
utils: add ifname argument to nm_utils_complete_generic() It's a common thing to complete a connection with an interface name; adding it to the common path is goint to save as a few tens of lines later on.
2019-05-07 10:15:10 +02:00
NULL,
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
TRUE);
s_dummy = nm_connection_get_setting_dummy (connection);
if (!s_dummy) {
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_INVALID_CONNECTION,
"A 'dummy' setting is required.");
return FALSE;
}
return TRUE;
}
static void
update_connection (NMDevice *device, NMConnection *connection)
{
NMSettingDummy *s_dummy = nm_connection_get_setting_dummy (connection);
if (!s_dummy) {
s_dummy = (NMSettingDummy *) nm_setting_dummy_new ();
nm_connection_add_setting (connection, (NMSetting *) s_dummy);
}
}
static gboolean
create_and_realize (NMDevice *device,
NMConnection *connection,
NMDevice *parent,
const NMPlatformLink **out_plink,
GError **error)
{
const char *iface = nm_device_get_iface (device);
NMSettingDummy *s_dummy;
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
int r;
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
s_dummy = nm_connection_get_setting_dummy (connection);
g_assert (s_dummy);
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
r = nm_platform_link_dummy_add (nm_device_get_platform (device), iface, out_plink);
if (r < 0) {
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_CREATION_FAILED,
"Failed to create dummy interface '%s' for '%s': %s",
iface,
nm_connection_get_id (connection),
platform: merge NMPlatformError with nm-error Platform had it's own scheme for reporting errors: NMPlatformError. Before, NMPlatformError indicated success via zero, negative integer values are numbers from <errno.h>, and positive integer values are platform specific codes. This changes now according to nm-error: success is still zero. Negative values indicate a failure, where the numeric value is either from <errno.h> or one of our error codes. The meaning of positive values depends on the functions. Most functions can only report an error reason (negative) and success (zero). For such functions, positive values should never be returned (but the caller should anticipate them). For some functions, positive values could mean additional information (but still success). That depends. This is also what systemd does, except that systemd only returns (negative) integers from <errno.h>, while we merge our own error codes into the range of <errno.h>. The advantage is to get rid of one way how to signal errors. The other advantage is, that these error codes are compatible with all other nm-errno values. For example, previously negative values indicated error codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
nm_strerror (r));
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
return FALSE;
}
return TRUE;
}
static NMActStageReturn
device: rename reason argument for NMDeviceDummy And remove assertion for out-argument to be present. Follow-up to commit 437c12fc89e6da99ca3820ed23b6276d587ee2d4.
2017-02-22 21:46:11 +01:00
act_stage1_prepare (NMDevice *device, NMDeviceStateReason *out_failure_reason)
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
{
NMActStageReturn ret;
device: rename reason argument for NMDeviceDummy And remove assertion for out-argument to be present. Follow-up to commit 437c12fc89e6da99ca3820ed23b6276d587ee2d4.
2017-02-22 21:46:11 +01:00
ret = NM_DEVICE_CLASS (nm_device_dummy_parent_class)->act_stage1_prepare (device, out_failure_reason);
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
if (ret != NM_ACT_STAGE_RETURN_SUCCESS)
return ret;
if (!nm_device_hw_addr_set_cloned (device, nm_device_get_applied_connection (device), FALSE))
return NM_ACT_STAGE_RETURN_FAILURE;
return NM_ACT_STAGE_RETURN_SUCCESS;
}
/*****************************************************************************/
static void
nm_device_dummy_init (NMDeviceDummy *self)
{
}
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
static const NMDBusInterfaceInfoExtended interface_info_device_dummy = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT (
NM_DBUS_INTERFACE_DEVICE_DUMMY,
.signals = NM_DEFINE_GDBUS_SIGNAL_INFOS (
&nm_signal_info_property_changed_legacy,
),
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS (
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE_L ("HwAddress", "s", NM_DEVICE_HW_ADDRESS),
),
),
.legacy_property_changed = TRUE,
};
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
static void
nm_device_dummy_class_init (NMDeviceDummyClass *klass)
{
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS (klass);
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
NMDeviceClass *device_class = NM_DEVICE_CLASS (klass);
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-02-26 13:51:52 +01:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS (&interface_info_device_dummy);
device: replace NM_DEVICE_CLASS_DECLARE_TYPES() macro by explicit initialization It seems to me the NM_DEVICE_CLASS_DECLARE_TYPES() macro confuses more than helping. Let's explicitly initialize the two fields, albeit with another helper macro NM_DEVICE_DEFINE_LINK_TYPES() to get the list of link-types right. For consistency, also leave nop-lines like device_class->connection_type_supported = NULL; device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (); because all NMDevice class init methods should have this same boiler plate code and to make it explicit that this is intended. And there are only 3 occurences where this actually comes into play.
2018-07-10 09:26:42 +02:00
device_class->connection_type_supported = NM_SETTING_DUMMY_SETTING_NAME;
core: give better error reason why device is incompatible with profile Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*. This will be used to determine, whether the profile is fundamentally incompatible with the device, or whether just some other properties mismatch. That information will be importand during a plain `nmcli connection up`, where NetworkManager searches all devices for a device to activate. If no device is found (and multiple errors happened), we want to show the error that is most likely relevant for the user. Also note, how NMDevice's check_connection_compatible() uses the new class field "device_class->connection_type_check_compatible" to simplify checks for compatible profiles. The error reason is still unused.
2018-06-27 17:00:55 +02:00
device_class->connection_type_check_compatible = NM_SETTING_DUMMY_SETTING_NAME;
device: replace NM_DEVICE_CLASS_DECLARE_TYPES() macro by explicit initialization It seems to me the NM_DEVICE_CLASS_DECLARE_TYPES() macro confuses more than helping. Let's explicitly initialize the two fields, albeit with another helper macro NM_DEVICE_DEFINE_LINK_TYPES() to get the list of link-types right. For consistency, also leave nop-lines like device_class->connection_type_supported = NULL; device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (); because all NMDevice class init methods should have this same boiler plate code and to make it explicit that this is intended. And there are only 3 occurences where this actually comes into play.
2018-07-10 09:26:42 +02:00
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (NM_LINK_TYPE_DUMMY);
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
device_class->complete_connection = complete_connection;
device_class->create_and_realize = create_and_realize;
device_class->get_generic_capabilities = get_generic_capabilities;
device_class->update_connection = update_connection;
device_class->act_stage1_prepare = act_stage1_prepare;
device_class->get_configured_mtu = nm_device_get_configured_mtu_for_wired;
}
/*****************************************************************************/
#define NM_TYPE_DUMMY_DEVICE_FACTORY (nm_dummy_device_factory_get_type ())
#define NM_DUMMY_DEVICE_FACTORY(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_DUMMY_DEVICE_FACTORY, NMDummyDeviceFactory))
static NMDevice *
create_device (NMDeviceFactory *factory,
const char *iface,
const NMPlatformLink *plink,
NMConnection *connection,
gboolean *out_ignore)
{
return (NMDevice *) g_object_new (NM_TYPE_DEVICE_DUMMY,
NM_DEVICE_IFACE, iface,
NM_DEVICE_TYPE_DESC, "Dummy",
NM_DEVICE_DEVICE_TYPE, NM_DEVICE_TYPE_DUMMY,
NM_DEVICE_LINK_TYPE, NM_LINK_TYPE_DUMMY,
NULL);
}
NM_DEVICE_FACTORY_DEFINE_INTERNAL (DUMMY, Dummy, dummy,
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES (NM_LINK_TYPE_DUMMY)
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES (NM_SETTING_DUMMY_SETTING_NAME),
factory_class->create_device = create_device;
);
Reference in a new issue Copy permalink