2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2007 - 2013 Red Hat, Inc.
|
|
|
|
|
* Copyright (C) 2007 - 2008 Novell, Inc.
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
2021-02-12 15:01:09 +01:00
|
|
|
#include "libnm-core-impl/nm-default-libnm-core.h"
|
2014-11-13 10:07:02 -05:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#include "nm-setting-bluetooth.h"
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
#include <net/ethernet.h>
|
|
|
|
|
|
2017-05-22 19:31:43 +02:00
|
|
|
#include "nm-connection-private.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
#include "nm-setting-cdma.h"
|
|
|
|
|
#include "nm-setting-gsm.h"
|
|
|
|
|
#include "nm-setting-private.h"
|
2014-07-30 10:57:45 -04:00
|
|
|
#include "nm-utils.h"
|
|
|
|
|
#include "nm-utils-private.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* SECTION:nm-setting-bluetooth
|
|
|
|
|
* @short_description: Describes Bluetooth connection properties
|
|
|
|
|
*
|
|
|
|
|
* The #NMSettingBluetooth object is a #NMSetting subclass that describes
|
|
|
|
|
* properties necessary for connection to devices that provide network
|
|
|
|
|
* connections via the Bluetooth Dial-Up Networking (DUN) and Network Access
|
|
|
|
|
* Point (NAP) profiles.
|
|
|
|
|
**/
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
NM_GOBJECT_PROPERTIES_DEFINE_BASE(PROP_BDADDR, PROP_TYPE, );
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
typedef struct {
|
2014-07-30 10:57:45 -04:00
|
|
|
char *bdaddr;
|
2014-07-24 08:53:33 -04:00
|
|
|
char *type;
|
|
|
|
|
} NMSettingBluetoothPrivate;
|
|
|
|
|
|
2021-06-11 00:27:31 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingBluetooth:
|
|
|
|
|
*
|
|
|
|
|
* Bluetooth Settings
|
|
|
|
|
*/
|
|
|
|
|
struct _NMSettingBluetooth {
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
NMSetting parent;
|
|
|
|
|
NMSettingBluetoothPrivate _priv;
|
2021-06-11 00:27:31 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _NMSettingBluetoothClass {
|
|
|
|
|
NMSettingClass parent;
|
|
|
|
|
};
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
G_DEFINE_TYPE(NMSettingBluetooth, nm_setting_bluetooth, NM_TYPE_SETTING)
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#define NM_SETTING_BLUETOOTH_GET_PRIVATE(o) \
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
_NM_GET_PRIVATE(o, NMSettingBluetooth, NM_IS_SETTING_BLUETOOTH, NMSetting)
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_bluetooth_get_connection_type:
|
|
|
|
|
* @setting: the #NMSettingBluetooth
|
|
|
|
|
*
|
|
|
|
|
* Returns the connection method for communicating with the remote device (i.e.
|
|
|
|
|
* either DUN to a DUN-capable device or PANU to a NAP-capable device).
|
|
|
|
|
*
|
2017-05-22 18:47:42 +02:00
|
|
|
* Returns: the type, either %NM_SETTING_BLUETOOTH_TYPE_PANU,
|
|
|
|
|
* %NM_SETTING_BLUETOOTH_TYPE_NAP or %NM_SETTING_BLUETOOTH_TYPE_DUN
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_bluetooth_get_connection_type(NMSettingBluetooth *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_BLUETOOTH(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_BLUETOOTH_GET_PRIVATE(setting)->type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_bluetooth_get_bdaddr:
|
|
|
|
|
* @setting: the #NMSettingBluetooth
|
|
|
|
|
*
|
|
|
|
|
* Gets the Bluetooth address of the remote device which this setting
|
|
|
|
|
* describes a connection to.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the Bluetooth address
|
|
|
|
|
**/
|
2014-07-30 10:57:45 -04:00
|
|
|
const char *
|
2014-07-24 08:53:33 -04:00
|
|
|
nm_setting_bluetooth_get_bdaddr(NMSettingBluetooth *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_BLUETOOTH(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_BLUETOOTH_GET_PRIVATE(setting)->bdaddr;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-13 17:37:08 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static gboolean
|
2014-10-21 22:30:31 -04:00
|
|
|
verify(NMSetting *setting, NMConnection *connection, GError **error)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
|
|
|
|
NMSettingBluetoothPrivate *priv = NM_SETTING_BLUETOOTH_GET_PRIVATE(setting);
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *type;
|
2017-08-23 14:05:12 +02:00
|
|
|
gboolean missing_nap_bridge = FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-05-22 19:31:43 +02:00
|
|
|
if (priv->bdaddr && !nm_utils_hwaddr_valid(priv->bdaddr, ETH_ALEN)) {
|
2014-07-24 08:53:33 -04:00
|
|
|
g_set_error_literal(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("property is invalid"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_BDADDR);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-08-23 14:05:12 +02:00
|
|
|
type = priv->type;
|
|
|
|
|
if (!type) {
|
|
|
|
|
if (connection) {
|
|
|
|
|
/* We may infer the type from the (non-)existence of gsm/cdma/bridge settings. */
|
|
|
|
|
type = _nm_connection_detect_bluetooth_type(connection);
|
|
|
|
|
}
|
|
|
|
|
if (!type) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
}
|
|
|
|
|
|
2017-08-23 14:05:12 +02:00
|
|
|
if (!NM_IN_STRSET(type,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE_DUN,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE_NAP,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE_PANU)) {
|
|
|
|
|
nm_assert(priv->type == type);
|
2014-07-24 08:53:33 -04:00
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("'%s' is not a valid value for the property"),
|
2017-08-23 14:05:12 +02:00
|
|
|
type);
|
2014-07-24 08:53:33 -04:00
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/* Make sure the corresponding 'type' setting is present */
|
2017-08-23 14:05:12 +02:00
|
|
|
if (connection && nm_streq(type, NM_SETTING_BLUETOOTH_TYPE_DUN)) {
|
2014-07-24 08:53:33 -04:00
|
|
|
gboolean gsm = FALSE, cdma = FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-21 22:30:31 -04:00
|
|
|
gsm = !!nm_connection_get_setting_gsm(connection);
|
|
|
|
|
cdma = !!nm_connection_get_setting_cdma(connection);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
if (!gsm && !cdma) {
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
/* We can't return MISSING_SETTING here, because we don't know
|
|
|
|
|
* whether to prefix the message with NM_SETTING_GSM_SETTING_NAME or
|
|
|
|
|
* NM_SETTING_CDMA_SETTING_NAME.
|
|
|
|
|
*/
|
2014-07-24 08:53:33 -04:00
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_SETTING,
|
|
|
|
|
_("'%s' connection requires '%s' or '%s' setting"),
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE_DUN,
|
2014-07-24 08:53:33 -04:00
|
|
|
NM_SETTING_GSM_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CDMA_SETTING_NAME);
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
g_prefix_error(error, "%s: ", NM_SETTING_BLUETOOTH_SETTING_NAME);
|
2014-07-24 08:53:33 -04:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* PANU doesn't need a 'type' setting since no further configuration
|
|
|
|
|
* is required at the interface level.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-05-22 19:31:43 +02:00
|
|
|
/* NAP mode needs a bridge setting, and a bridge needs a name. */
|
2017-08-23 14:05:12 +02:00
|
|
|
if (nm_streq(type, NM_SETTING_BLUETOOTH_TYPE_NAP)) {
|
2017-05-22 19:31:43 +02:00
|
|
|
if (!_nm_connection_verify_required_interface_name(connection, error))
|
|
|
|
|
return FALSE;
|
2017-08-23 14:05:12 +02:00
|
|
|
if (connection && !nm_connection_get_setting_bridge(connection))
|
|
|
|
|
missing_nap_bridge = TRUE;
|
2017-05-22 19:31:43 +02:00
|
|
|
} else {
|
|
|
|
|
if (!priv->bdaddr) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_BDADDR);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-08-23 14:05:12 +02:00
|
|
|
/* errors form here are normalizable. */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-08-23 14:05:12 +02:00
|
|
|
if (!priv->type) {
|
|
|
|
|
/* as determined above, we can detect the bluetooth type. */
|
|
|
|
|
nm_assert(!missing_nap_bridge);
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-08-23 14:05:12 +02:00
|
|
|
if (missing_nap_bridge) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_SETTING,
|
|
|
|
|
_("'%s' connection requires '%s' setting"),
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE_NAP,
|
|
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME);
|
|
|
|
|
g_prefix_error(error, "%s: ", NM_SETTING_BLUETOOTH_SETTING_NAME);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
static void
|
2019-01-11 08:32:54 +01:00
|
|
|
nm_setting_bluetooth_init(NMSettingBluetooth *setting)
|
|
|
|
|
{}
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/**
|
|
|
|
|
* nm_setting_bluetooth_new:
|
|
|
|
|
*
|
|
|
|
|
* Creates a new #NMSettingBluetooth object with default values.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new empty #NMSettingBluetooth object
|
|
|
|
|
**/
|
|
|
|
|
NMSetting *
|
|
|
|
|
nm_setting_bluetooth_new(void)
|
|
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_SETTING_BLUETOOTH, NULL);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static void
|
libnm/trivial: cleanup variable names in settings' class-init functions
- Don't use @parent_class name. This local variable (and @object_class) is
the class instance up-cast to the pointer types of the parents. The point
here is not that it is the direct parent. The point is, that it's the
NMSettingClass type.
Also, it can only be used inconsistently, in face of NMSettingIP4Config,
who's parent type is NMSettingIPConfig. Clearly, inside
nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
name. Consistently rename @parent_class to @setting_class.
- Also rename the pointer to the own class to @klass. "setting_class" is also the
wrong name for that, because the right name would be something like
"setting_6lowpan_class".
However, "klass" is preferred over the latter, because we commonly create new
GObject implementations by copying an existing one. Generic names like "klass"
and "self" inside a type implementation make that simpler.
- drop useless comments like
/* virtual functions */
/* Properties */
It's better to logically and visually structure the code, and avoid trival
remarks about that. They only end up being used inconsistently. If you
even need a stronger visual separator, then an 80 char /****/ line
should be preferred.
2018-07-28 10:43:21 +02:00
|
|
|
nm_setting_bluetooth_class_init(NMSettingBluetoothClass *klass)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS(klass);
|
libnm/trivial: cleanup variable names in settings' class-init functions
- Don't use @parent_class name. This local variable (and @object_class) is
the class instance up-cast to the pointer types of the parents. The point
here is not that it is the direct parent. The point is, that it's the
NMSettingClass type.
Also, it can only be used inconsistently, in face of NMSettingIP4Config,
who's parent type is NMSettingIPConfig. Clearly, inside
nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
name. Consistently rename @parent_class to @setting_class.
- Also rename the pointer to the own class to @klass. "setting_class" is also the
wrong name for that, because the right name would be something like
"setting_6lowpan_class".
However, "klass" is preferred over the latter, because we commonly create new
GObject implementations by copying an existing one. Generic names like "klass"
and "self" inside a type implementation make that simpler.
- drop useless comments like
/* virtual functions */
/* Properties */
It's better to logically and visually structure the code, and avoid trival
remarks about that. They only end up being used inconsistently. If you
even need a stronger visual separator, then an 80 char /****/ line
should be preferred.
2018-07-28 10:43:21 +02:00
|
|
|
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
|
2021-11-09 13:28:54 +01:00
|
|
|
GArray *properties_override = _nm_sett_info_property_override_create_array();
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2021-07-13 17:37:08 +02:00
|
|
|
object_class->get_property = _nm_setting_property_get_property_direct;
|
2021-07-14 07:40:35 +02:00
|
|
|
object_class->set_property = _nm_setting_property_set_property_direct;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2021-10-23 20:58:27 +02:00
|
|
|
setting_class->verify = verify;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMSettingBluetooth:bdaddr:
|
|
|
|
|
*
|
|
|
|
|
* The Bluetooth address of the device.
|
|
|
|
|
**/
|
2021-07-14 07:40:35 +02:00
|
|
|
_nm_setting_property_define_direct_mac_address(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_BLUETOOTH_BDADDR,
|
|
|
|
|
PROP_BDADDR,
|
|
|
|
|
NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NMSettingBluetoothPrivate,
|
|
|
|
|
bdaddr,
|
|
|
|
|
.direct_set_string_mac_address_len = ETH_ALEN);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingBluetooth:type:
|
|
|
|
|
*
|
|
|
|
|
* Either "dun" for Dial-Up Networking connections or "panu" for Personal
|
|
|
|
|
* Area Networking connections to devices supporting the NAP profile.
|
|
|
|
|
**/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_BLUETOOTH_TYPE,
|
|
|
|
|
PROP_TYPE,
|
|
|
|
|
NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NMSettingBluetoothPrivate,
|
2024-01-08 11:46:53 +01:00
|
|
|
type,
|
|
|
|
|
.direct_string_allow_empty = TRUE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-11 08:28:26 +01:00
|
|
|
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-06-28 14:53:16 +02:00
|
|
|
_nm_setting_class_commit(setting_class,
|
|
|
|
|
NM_META_SETTING_TYPE_BLUETOOTH,
|
|
|
|
|
NULL,
|
|
|
|
|
properties_override,
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
G_STRUCT_OFFSET(NMSettingBluetooth, _priv));
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
