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 - 2018 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-serial.h"
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
#include "nm-setting-private.h"
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* SECTION:nm-setting-serial
|
|
|
|
|
* @short_description: Describes connection properties for devices that use
|
|
|
|
|
* serial communications
|
|
|
|
|
*
|
|
|
|
|
* The #NMSettingSerial object is a #NMSetting subclass that describes
|
|
|
|
|
* properties necessary for connections that may use serial communications,
|
|
|
|
|
* such as mobile broadband or analog telephone connections.
|
|
|
|
|
**/
|
|
|
|
|
|
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_BAUD,
|
|
|
|
|
PROP_BITS,
|
|
|
|
|
PROP_PARITY,
|
|
|
|
|
PROP_STOPBITS,
|
|
|
|
|
PROP_SEND_DELAY, );
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
typedef struct {
|
2019-12-12 11:51:21 +01:00
|
|
|
guint64 send_delay;
|
2021-10-20 16:13:14 +02:00
|
|
|
guint32 baud;
|
|
|
|
|
guint32 bits;
|
|
|
|
|
guint32 stopbits;
|
2019-12-12 11:51:21 +01:00
|
|
|
char parity;
|
2014-07-24 08:53:33 -04:00
|
|
|
} NMSettingSerialPrivate;
|
|
|
|
|
|
2021-06-11 00:27:31 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:
|
|
|
|
|
*
|
|
|
|
|
* Serial Link Settings
|
|
|
|
|
*/
|
|
|
|
|
struct _NMSettingSerial {
|
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;
|
|
|
|
|
NMSettingSerialPrivate _priv;
|
2021-06-11 00:27:31 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _NMSettingSerialClass {
|
|
|
|
|
NMSettingClass parent;
|
|
|
|
|
};
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
G_DEFINE_TYPE(NMSettingSerial, nm_setting_serial, NM_TYPE_SETTING)
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#define NM_SETTING_SERIAL_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, NMSettingSerial, NM_IS_SETTING_SERIAL, NMSetting)
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_get_baud:
|
|
|
|
|
* @setting: the #NMSettingSerial
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingSerial:baud property of the setting
|
|
|
|
|
**/
|
|
|
|
|
guint
|
|
|
|
|
nm_setting_serial_get_baud(NMSettingSerial *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_SERIAL(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_SERIAL_GET_PRIVATE(setting)->baud;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_get_bits:
|
|
|
|
|
* @setting: the #NMSettingSerial
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingSerial:bits property of the setting
|
|
|
|
|
**/
|
|
|
|
|
guint
|
|
|
|
|
nm_setting_serial_get_bits(NMSettingSerial *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_SERIAL(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_SERIAL_GET_PRIVATE(setting)->bits;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_get_parity:
|
|
|
|
|
* @setting: the #NMSettingSerial
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingSerial:parity property of the setting
|
|
|
|
|
**/
|
2014-09-24 09:12:46 -04:00
|
|
|
NMSettingSerialParity
|
2014-07-24 08:53:33 -04:00
|
|
|
nm_setting_serial_get_parity(NMSettingSerial *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_SERIAL(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_SERIAL_GET_PRIVATE(setting)->parity;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_get_stopbits:
|
|
|
|
|
* @setting: the #NMSettingSerial
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingSerial:stopbits property of the setting
|
|
|
|
|
**/
|
|
|
|
|
guint
|
|
|
|
|
nm_setting_serial_get_stopbits(NMSettingSerial *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_SERIAL(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_SERIAL_GET_PRIVATE(setting)->stopbits;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_get_send_delay:
|
|
|
|
|
* @setting: the #NMSettingSerial
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingSerial:send-delay property of the setting
|
|
|
|
|
**/
|
|
|
|
|
guint64
|
|
|
|
|
nm_setting_serial_get_send_delay(NMSettingSerial *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_SERIAL(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_SERIAL_GET_PRIVATE(setting)->send_delay;
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-20 16:13:14 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2014-09-24 09:12:46 -04:00
|
|
|
static GVariant *
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
parity_to_dbus_fcn(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2014-09-24 09:12:46 -04:00
|
|
|
{
|
2021-06-29 20:11:34 +02:00
|
|
|
switch (nm_setting_serial_get_parity(NM_SETTING_SERIAL(setting))) {
|
2014-09-24 09:12:46 -04:00
|
|
|
case NM_SETTING_SERIAL_PARITY_EVEN:
|
|
|
|
|
return g_variant_new_byte('E');
|
|
|
|
|
case NM_SETTING_SERIAL_PARITY_ODD:
|
|
|
|
|
return g_variant_new_byte('o');
|
|
|
|
|
case NM_SETTING_SERIAL_PARITY_NONE:
|
2021-06-29 20:11:34 +02:00
|
|
|
/* the default, serializes to NULL. */
|
|
|
|
|
return NULL;
|
2014-09-24 09:12:46 -04:00
|
|
|
default:
|
2021-06-29 20:11:34 +02:00
|
|
|
return NULL;
|
2014-09-24 09:12:46 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
parity_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_GPROP_FCN_ARGS _nm_nil)
|
2014-09-24 09:12:46 -04:00
|
|
|
{
|
|
|
|
|
switch (g_variant_get_byte(from)) {
|
|
|
|
|
case 'E':
|
|
|
|
|
g_value_set_enum(to, NM_SETTING_SERIAL_PARITY_EVEN);
|
|
|
|
|
break;
|
|
|
|
|
case 'o':
|
|
|
|
|
g_value_set_enum(to, NM_SETTING_SERIAL_PARITY_ODD);
|
|
|
|
|
break;
|
|
|
|
|
case 'n':
|
|
|
|
|
default:
|
|
|
|
|
g_value_set_enum(to, NM_SETTING_SERIAL_PARITY_NONE);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2019-01-11 08:32:54 +01:00
|
|
|
NMSettingSerial *setting = NM_SETTING_SERIAL(object);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
switch (prop_id) {
|
|
|
|
|
case PROP_PARITY:
|
2019-01-11 08:32:54 +01:00
|
|
|
g_value_set_enum(value, nm_setting_serial_get_parity(setting));
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
default:
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_get_property_direct(object, prop_id, value, pspec);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2019-01-11 08:32:54 +01:00
|
|
|
set_property(GObject *object, guint prop_id, const GValue *value, GParamSpec *pspec)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2019-01-11 08:32:54 +01:00
|
|
|
NMSettingSerialPrivate *priv = NM_SETTING_SERIAL_GET_PRIVATE(object);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
switch (prop_id) {
|
|
|
|
|
case PROP_PARITY:
|
2019-01-11 08:32:54 +01:00
|
|
|
priv->parity = g_value_get_enum(value);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
default:
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_set_property_direct(object, prop_id, value, pspec);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static void
|
2019-12-12 11:52:11 +01:00
|
|
|
nm_setting_serial_init(NMSettingSerial *self)
|
2019-01-11 08:32:54 +01:00
|
|
|
{
|
2019-12-12 11:52:11 +01:00
|
|
|
NMSettingSerialPrivate *priv = NM_SETTING_SERIAL_GET_PRIVATE(self);
|
|
|
|
|
|
|
|
|
|
nm_assert(priv->parity == NM_SETTING_SERIAL_PARITY_NONE);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_serial_new:
|
|
|
|
|
*
|
|
|
|
|
* Creates a new #NMSettingSerial object with default values.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new empty #NMSettingSerial object
|
|
|
|
|
**/
|
|
|
|
|
NMSetting *
|
|
|
|
|
nm_setting_serial_new(void)
|
|
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_SETTING_SERIAL, 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_serial_class_init(NMSettingSerialClass *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
|
|
|
|
|
|
|
|
object_class->get_property = get_property;
|
2019-01-11 08:32:54 +01:00
|
|
|
object_class->set_property = set_property;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:baud:
|
|
|
|
|
*
|
|
|
|
|
* Speed to use for communication over the serial port. Note that this
|
|
|
|
|
* value usually has no effect for mobile broadband modems as they generally
|
|
|
|
|
* ignore speed settings and use the highest available speed.
|
|
|
|
|
**/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_uint32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_SERIAL_BAUD,
|
|
|
|
|
PROP_BAUD,
|
|
|
|
|
0,
|
|
|
|
|
G_MAXUINT32,
|
|
|
|
|
57600,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingSerialPrivate,
|
|
|
|
|
baud);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:bits:
|
|
|
|
|
*
|
|
|
|
|
* Byte-width of the serial communication. The 8 in "8n1" for example.
|
|
|
|
|
**/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_uint32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_SERIAL_BITS,
|
|
|
|
|
PROP_BITS,
|
|
|
|
|
5,
|
|
|
|
|
8,
|
|
|
|
|
8,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingSerialPrivate,
|
|
|
|
|
bits);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:parity:
|
|
|
|
|
*
|
2014-09-24 09:12:46 -04:00
|
|
|
* Parity setting of the serial port.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---keyfile---
|
|
|
|
|
* property: parity
|
|
|
|
|
* format: 'e', 'o', or 'n'
|
|
|
|
|
* description: The connection parity; even, odd, or none. Note that older
|
|
|
|
|
* versions of NetworkManager stored this as an integer: 69 ('E') for even,
|
|
|
|
|
* 111 ('o') for odd, or 110 ('n') for none.
|
|
|
|
|
* example: parity=n
|
|
|
|
|
* ---end---
|
2022-08-29 15:05:39 +02:00
|
|
|
*/
|
|
|
|
|
/* ---dbus---
|
2014-11-16 15:36:18 -05:00
|
|
|
* property: parity
|
|
|
|
|
* format: byte
|
|
|
|
|
* description: The connection parity: 69 (ASCII 'E') for even parity,
|
|
|
|
|
* 111 (ASCII 'o') for odd, 110 (ASCII 'n') for none.
|
|
|
|
|
* ---end---
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
*/
|
2019-01-11 08:28:26 +01:00
|
|
|
obj_properties[PROP_PARITY] = g_param_spec_enum(NM_SETTING_SERIAL_PARITY,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NM_TYPE_SETTING_SERIAL_PARITY,
|
|
|
|
|
NM_SETTING_SERIAL_PARITY_NONE,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
2019-09-22 15:32:04 +02:00
|
|
|
_nm_properties_override_gobj(
|
|
|
|
|
properties_override,
|
|
|
|
|
obj_properties[PROP_PARITY],
|
2021-06-29 20:11:34 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_BYTE,
|
|
|
|
|
.compare_fcn = _nm_setting_property_compare_fcn_default,
|
|
|
|
|
.to_dbus_fcn = parity_to_dbus_fcn,
|
2021-06-30 00:05:49 +02:00
|
|
|
.typdata_from_dbus.gprop_fcn = parity_from_dbus,
|
|
|
|
|
.from_dbus_fcn = _nm_setting_property_from_dbus_fcn_gprop,
|
|
|
|
|
.from_dbus_is_full = TRUE));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:stopbits:
|
|
|
|
|
*
|
|
|
|
|
* Number of stop bits for communication on the serial port. Either 1 or 2.
|
|
|
|
|
* The 1 in "8n1" for example.
|
|
|
|
|
**/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_uint32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_SERIAL_STOPBITS,
|
|
|
|
|
PROP_STOPBITS,
|
|
|
|
|
1,
|
|
|
|
|
2,
|
|
|
|
|
1,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingSerialPrivate,
|
|
|
|
|
stopbits);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingSerial:send-delay:
|
|
|
|
|
*
|
|
|
|
|
* Time to delay between each byte sent to the modem, in microseconds.
|
|
|
|
|
**/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_uint64(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_SERIAL_SEND_DELAY,
|
|
|
|
|
PROP_SEND_DELAY,
|
|
|
|
|
0,
|
|
|
|
|
G_MAXUINT64,
|
|
|
|
|
0,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingSerialPrivate,
|
|
|
|
|
send_delay);
|
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_SERIAL,
|
|
|
|
|
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(NMSettingSerial, _priv));
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|