2020-09-29 16:42:22 +02:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1+ */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2017 Red Hat, Inc.
|
|
|
|
|
* Copyright (C) 2013 Jiri Pirko <jiri@resnulli.us>
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
2016-02-19 14:57:48 +01:00
|
|
|
#include "nm-default.h"
|
2014-11-13 10:07:02 -05:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
#include "nm-setting-team.h"
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
|
|
|
|
#include "nm-utils.h"
|
|
|
|
|
#include "nm-utils-private.h"
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
#include "nm-team-utils.h"
|
2014-10-21 22:30:31 -04:00
|
|
|
#include "nm-connection-private.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* SECTION:nm-setting-team
|
|
|
|
|
* @short_description: Describes connection properties for teams
|
|
|
|
|
*
|
|
|
|
|
* The #NMSettingTeam object is a #NMSetting subclass that describes properties
|
|
|
|
|
* necessary for team connections.
|
|
|
|
|
**/
|
|
|
|
|
|
2017-11-02 17:13:46 +01:00
|
|
|
/*****************************************************************************
|
2019-05-11 10:24:15 +02:00
|
|
|
* NMTeamLinkWatcher
|
2017-11-02 17:13:46 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
G_DEFINE_BOXED_TYPE(NMTeamLinkWatcher,
|
|
|
|
|
nm_team_link_watcher,
|
|
|
|
|
_nm_team_link_watcher_ref,
|
|
|
|
|
nm_team_link_watcher_unref)
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2019-05-11 11:04:28 +02:00
|
|
|
typedef enum {
|
2020-09-28 16:03:33 +02:00
|
|
|
LINK_WATCHER_ETHTOOL = 0,
|
|
|
|
|
LINK_WATCHER_NSNA_PING = 1,
|
|
|
|
|
LINK_WATCHER_ARP_PING = 2,
|
2019-05-11 11:04:28 +02:00
|
|
|
} LinkWatcherTypes;
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
static const char *_link_watcher_name[] = {[LINK_WATCHER_ETHTOOL] = NM_TEAM_LINK_WATCHER_ETHTOOL,
|
|
|
|
|
[LINK_WATCHER_NSNA_PING] =
|
|
|
|
|
NM_TEAM_LINK_WATCHER_NSNA_PING,
|
|
|
|
|
[LINK_WATCHER_ARP_PING] = NM_TEAM_LINK_WATCHER_ARP_PING};
|
2017-11-02 17:13:46 +01:00
|
|
|
|
|
|
|
|
struct NMTeamLinkWatcher {
|
2020-09-28 16:03:33 +02:00
|
|
|
int ref_count;
|
|
|
|
|
|
|
|
|
|
guint8 type; /* LinkWatcherTypes */
|
|
|
|
|
|
|
|
|
|
union {
|
|
|
|
|
struct {
|
|
|
|
|
int delay_up;
|
|
|
|
|
int delay_down;
|
|
|
|
|
} ethtool;
|
|
|
|
|
struct {
|
|
|
|
|
const char *target_host;
|
|
|
|
|
int init_wait;
|
|
|
|
|
int interval;
|
|
|
|
|
int missed_max;
|
|
|
|
|
} nsna_ping;
|
|
|
|
|
struct {
|
|
|
|
|
const char * target_host;
|
|
|
|
|
const char * source_host;
|
|
|
|
|
int init_wait;
|
|
|
|
|
int interval;
|
|
|
|
|
int missed_max;
|
|
|
|
|
int vlanid;
|
|
|
|
|
NMTeamLinkWatcherArpPingFlags flags;
|
|
|
|
|
} arp_ping;
|
|
|
|
|
};
|
2017-11-02 17:13:46 +01:00
|
|
|
};
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#define _CHECK_WATCHER_VOID(watcher) \
|
|
|
|
|
G_STMT_START \
|
|
|
|
|
{ \
|
|
|
|
|
g_return_if_fail(watcher != NULL); \
|
|
|
|
|
g_return_if_fail(watcher->ref_count > 0); \
|
|
|
|
|
nm_assert(watcher->type <= LINK_WATCHER_ARP_PING); \
|
|
|
|
|
} \
|
|
|
|
|
G_STMT_END
|
|
|
|
|
|
|
|
|
|
#define _CHECK_WATCHER(watcher, err_val) \
|
|
|
|
|
G_STMT_START \
|
|
|
|
|
{ \
|
|
|
|
|
g_return_val_if_fail(watcher != NULL, err_val); \
|
|
|
|
|
g_return_val_if_fail(watcher->ref_count > 0, err_val); \
|
|
|
|
|
nm_assert(watcher->type <= LINK_WATCHER_ARP_PING); \
|
|
|
|
|
} \
|
|
|
|
|
G_STMT_END
|
2017-11-02 17:13:46 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_new_ethtool:
|
|
|
|
|
* @delay_up: delay_up value
|
|
|
|
|
* @delay_down: delay_down value
|
|
|
|
|
* @error: this call never fails, so this var is not used but kept for format
|
|
|
|
|
* consistency with the link_watcher constructors of other type
|
|
|
|
|
*
|
|
|
|
|
* Creates a new ethtool #NMTeamLinkWatcher object
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new #NMTeamLinkWatcher object
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_new_ethtool(int delay_up, int delay_down, GError **error)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMTeamLinkWatcher *watcher;
|
|
|
|
|
const char * val_fail = NULL;
|
|
|
|
|
|
|
|
|
|
if (delay_up < 0 || !_NM_INT_LE_MAXINT32(delay_up))
|
|
|
|
|
val_fail = "delay-up";
|
|
|
|
|
if (delay_down < 0 || !_NM_INT_LE_MAXINT32(delay_down))
|
|
|
|
|
val_fail = "delay-down";
|
|
|
|
|
if (val_fail) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("%s is out of range [0, %d]"),
|
|
|
|
|
val_fail,
|
|
|
|
|
G_MAXINT32);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
libnm: suppress "-Warray-bounds" warning in nm_team_link_watcher_new_ethtool()
gcc-11.0.0-0.7.fc34 warns here:
CC libnm-core/libnm_core_la-nm-setting-team.lo
libnm-core/nm-setting-team.c: In function ‘nm_team_link_watcher_new_ethtool’:
libnm-core/nm-setting-team.c:127:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
127 | watcher->ref_count = 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:128:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
128 | watcher->type = LINK_WATCHER_ETHTOOL;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:129:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
129 | watcher->ethtool.delay_up = delay_up;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:130:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
130 | watcher->ethtool.delay_down = delay_down;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe we should not use this trick and just malloc() a struct of the
intended size, however:
- the code below does a similar thing, doing it differently for ethtool
watcher is confusing.
- the NMTeamLinkWatcher is a union which cannot alter its type. In no
case is it correct to access the fields of the wrong union type. By
allocating a smaller chunk, valgrind might catch such bugs.
Also, NMTeamLinkWatcher's definition is private to the C source file,
in no case must anybody assume that the rest of the buffer actually
exists.
Hence, workaround the warning by suppressing it.
2020-12-11 11:43:38 +01:00
|
|
|
NM_PRAGMA_WARNING_DISABLE("-Warray-bounds")
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
|
|
|
|
|
|
|
|
|
|
watcher->ref_count = 1;
|
|
|
|
|
watcher->type = LINK_WATCHER_ETHTOOL;
|
|
|
|
|
watcher->ethtool.delay_up = delay_up;
|
|
|
|
|
watcher->ethtool.delay_down = delay_down;
|
|
|
|
|
|
libnm: suppress "-Warray-bounds" warning in nm_team_link_watcher_new_ethtool()
gcc-11.0.0-0.7.fc34 warns here:
CC libnm-core/libnm_core_la-nm-setting-team.lo
libnm-core/nm-setting-team.c: In function ‘nm_team_link_watcher_new_ethtool’:
libnm-core/nm-setting-team.c:127:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
127 | watcher->ref_count = 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:128:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
128 | watcher->type = LINK_WATCHER_ETHTOOL;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:129:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
129 | watcher->ethtool.delay_up = delay_up;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:130:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
130 | watcher->ethtool.delay_down = delay_down;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe we should not use this trick and just malloc() a struct of the
intended size, however:
- the code below does a similar thing, doing it differently for ethtool
watcher is confusing.
- the NMTeamLinkWatcher is a union which cannot alter its type. In no
case is it correct to access the fields of the wrong union type. By
allocating a smaller chunk, valgrind might catch such bugs.
Also, NMTeamLinkWatcher's definition is private to the C source file,
in no case must anybody assume that the rest of the buffer actually
exists.
Hence, workaround the warning by suppressing it.
2020-12-11 11:43:38 +01:00
|
|
|
NM_PRAGMA_WARNING_REENABLE
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return watcher;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_new_nsna_ping:
|
|
|
|
|
* @init_wait: init_wait value
|
|
|
|
|
* @interval: interval value
|
|
|
|
|
* @missed_max: missed_max value
|
|
|
|
|
* @target_host: the host name or the ipv6 address that will be used as
|
|
|
|
|
* target address in the NS packet
|
|
|
|
|
* @error: (out) (allow-none): location to store the error on failure
|
|
|
|
|
*
|
|
|
|
|
* Creates a new nsna_ping #NMTeamLinkWatcher object
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new #NMTeamLinkWatcher object, or %NULL on error
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_new_nsna_ping(int init_wait,
|
|
|
|
|
int interval,
|
|
|
|
|
int missed_max,
|
|
|
|
|
const char *target_host,
|
|
|
|
|
GError ** error)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMTeamLinkWatcher *watcher;
|
|
|
|
|
const char * val_fail = NULL;
|
|
|
|
|
char * str;
|
|
|
|
|
gsize l_target_host;
|
|
|
|
|
|
|
|
|
|
if (!target_host) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("Missing target-host in nsna_ping link watcher"));
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (strpbrk(target_host, " \\/\t=\"\'")) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("target-host '%s' contains invalid characters"),
|
|
|
|
|
target_host);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (init_wait < 0 || !_NM_INT_LE_MAXINT32(init_wait))
|
|
|
|
|
val_fail = "init-wait";
|
|
|
|
|
if (interval < 0 || !_NM_INT_LE_MAXINT32(interval))
|
|
|
|
|
val_fail = "interval";
|
|
|
|
|
if (missed_max < 0 || !_NM_INT_LE_MAXINT32(missed_max))
|
|
|
|
|
val_fail = "missed-max";
|
|
|
|
|
if (val_fail) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("%s is out of range [0, %d]"),
|
|
|
|
|
val_fail,
|
|
|
|
|
G_MAXINT32);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
l_target_host = strlen(target_host) + 1;
|
|
|
|
|
|
|
|
|
|
watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, nsna_ping) + l_target_host);
|
|
|
|
|
|
|
|
|
|
watcher->ref_count = 1;
|
|
|
|
|
watcher->type = LINK_WATCHER_NSNA_PING;
|
|
|
|
|
watcher->nsna_ping.init_wait = init_wait;
|
|
|
|
|
watcher->nsna_ping.interval = interval;
|
|
|
|
|
watcher->nsna_ping.missed_max = missed_max;
|
|
|
|
|
|
|
|
|
|
str = &((char *) watcher)[nm_offsetofend(NMTeamLinkWatcher, nsna_ping)];
|
|
|
|
|
watcher->nsna_ping.target_host = str;
|
|
|
|
|
memcpy(str, target_host, l_target_host);
|
|
|
|
|
|
|
|
|
|
return watcher;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_new_arp_ping:
|
|
|
|
|
* @init_wait: init_wait value
|
|
|
|
|
* @interval: interval value
|
|
|
|
|
* @missed_max: missed_max value
|
|
|
|
|
* @target_host: the host name or the ip address that will be used as destination
|
|
|
|
|
* address in the arp request
|
|
|
|
|
* @source_host: the host name or the ip address that will be used as source
|
|
|
|
|
* address in the arp request
|
|
|
|
|
* @flags: the watcher #NMTeamLinkWatcherArpPingFlags
|
|
|
|
|
* @error: (out) (allow-none): location to store the error on failure
|
|
|
|
|
*
|
|
|
|
|
* Creates a new arp_ping #NMTeamLinkWatcher object
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new #NMTeamLinkWatcher object, or %NULL on error
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_new_arp_ping(int init_wait,
|
|
|
|
|
int interval,
|
|
|
|
|
int missed_max,
|
|
|
|
|
const char * target_host,
|
|
|
|
|
const char * source_host,
|
|
|
|
|
NMTeamLinkWatcherArpPingFlags flags,
|
|
|
|
|
GError ** error)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return nm_team_link_watcher_new_arp_ping2(init_wait,
|
|
|
|
|
interval,
|
|
|
|
|
missed_max,
|
|
|
|
|
-1,
|
|
|
|
|
target_host,
|
|
|
|
|
source_host,
|
|
|
|
|
flags,
|
|
|
|
|
error);
|
2018-12-05 15:26:50 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_new_arp_ping2:
|
|
|
|
|
* @init_wait: init_wait value
|
|
|
|
|
* @interval: interval value
|
|
|
|
|
* @missed_max: missed_max value
|
|
|
|
|
* @vlanid: vlanid value
|
|
|
|
|
* @target_host: the host name or the ip address that will be used as destination
|
|
|
|
|
* address in the arp request
|
|
|
|
|
* @source_host: the host name or the ip address that will be used as source
|
|
|
|
|
* address in the arp request
|
|
|
|
|
* @flags: the watcher #NMTeamLinkWatcherArpPingFlags
|
|
|
|
|
* @error: (out) (allow-none): location to store the error on failure
|
|
|
|
|
*
|
|
|
|
|
* Creates a new arp_ping #NMTeamLinkWatcher object
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new #NMTeamLinkWatcher object, or %NULL on error
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.16
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_new_arp_ping2(int init_wait,
|
|
|
|
|
int interval,
|
|
|
|
|
int missed_max,
|
|
|
|
|
int vlanid,
|
|
|
|
|
const char * target_host,
|
|
|
|
|
const char * source_host,
|
|
|
|
|
NMTeamLinkWatcherArpPingFlags flags,
|
|
|
|
|
GError ** error)
|
2018-12-05 15:26:50 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMTeamLinkWatcher *watcher;
|
|
|
|
|
const char * val_fail = NULL;
|
|
|
|
|
char * str;
|
|
|
|
|
gsize l_target_host;
|
|
|
|
|
gsize l_source_host;
|
|
|
|
|
|
|
|
|
|
if (!target_host || !source_host) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("Missing %s in arp_ping link watcher"),
|
|
|
|
|
target_host ? "source-host" : "target-host");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (strpbrk(target_host, " \\/\t=\"\'")) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("target-host '%s' contains invalid characters"),
|
|
|
|
|
target_host);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (strpbrk(source_host, " \\/\t=\"\'")) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("source-host '%s' contains invalid characters"),
|
|
|
|
|
source_host);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
else if (init_wait < 0 || !_NM_INT_LE_MAXINT32(init_wait))
|
|
|
|
|
val_fail = "init-wait";
|
|
|
|
|
else if (interval < 0 || !_NM_INT_LE_MAXINT32(interval))
|
|
|
|
|
val_fail = "interval";
|
|
|
|
|
else if (missed_max < 0 || !_NM_INT_LE_MAXINT32(missed_max))
|
|
|
|
|
val_fail = "missed-max";
|
|
|
|
|
if (val_fail) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("%s is out of range [0, %d]"),
|
|
|
|
|
val_fail,
|
|
|
|
|
G_MAXINT32);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vlanid < -1 || vlanid > 4094) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_FAILED,
|
|
|
|
|
_("vlanid is out of range [-1, 4094]"));
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
l_target_host = strlen(target_host) + 1;
|
|
|
|
|
l_source_host = strlen(source_host) + 1;
|
|
|
|
|
|
|
|
|
|
watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, arp_ping) + l_target_host + l_source_host);
|
|
|
|
|
|
|
|
|
|
watcher->ref_count = 1;
|
|
|
|
|
watcher->type = LINK_WATCHER_ARP_PING;
|
|
|
|
|
watcher->arp_ping.init_wait = init_wait;
|
|
|
|
|
watcher->arp_ping.interval = interval;
|
|
|
|
|
watcher->arp_ping.missed_max = missed_max;
|
|
|
|
|
watcher->arp_ping.flags = flags;
|
|
|
|
|
watcher->arp_ping.vlanid = vlanid;
|
|
|
|
|
|
|
|
|
|
str = &((char *) watcher)[nm_offsetofend(NMTeamLinkWatcher, arp_ping)];
|
|
|
|
|
watcher->arp_ping.target_host = str;
|
|
|
|
|
memcpy(str, target_host, l_target_host);
|
|
|
|
|
|
|
|
|
|
str += l_target_host;
|
|
|
|
|
watcher->arp_ping.source_host = str;
|
|
|
|
|
memcpy(str, source_host, l_source_host);
|
|
|
|
|
|
|
|
|
|
return watcher;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-12 12:13:28 +02:00
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_team_link_watcher_ref(NMTeamLinkWatcher *watcher)
|
2019-05-12 12:13:28 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, NULL);
|
2019-05-12 12:13:28 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_atomic_int_inc(&watcher->ref_count);
|
|
|
|
|
return watcher;
|
2019-05-12 12:13:28 +02:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 17:13:46 +01:00
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_ref:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Increases the reference count of the object.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_ref(NMTeamLinkWatcher *watcher)
|
2019-05-12 12:13:28 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_team_link_watcher_ref(watcher);
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_unref:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Decreases the reference count of the object. If the reference count
|
|
|
|
|
* reaches zero, the object will be destroyed.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_unref(NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER_VOID(watcher);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (g_atomic_int_dec_and_test(&watcher->ref_count))
|
|
|
|
|
g_free(watcher);
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-11 10:31:57 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_cmp(const NMTeamLinkWatcher *watcher, const NMTeamLinkWatcher *other)
|
2019-05-11 10:31:57 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NM_CMP_SELF(watcher, other);
|
|
|
|
|
|
|
|
|
|
NM_CMP_FIELD(watcher, other, type);
|
|
|
|
|
|
|
|
|
|
switch (watcher->type) {
|
|
|
|
|
case LINK_WATCHER_ETHTOOL:
|
|
|
|
|
NM_CMP_FIELD(watcher, other, ethtool.delay_up);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, ethtool.delay_down);
|
|
|
|
|
break;
|
|
|
|
|
case LINK_WATCHER_NSNA_PING:
|
|
|
|
|
NM_CMP_FIELD_STR(watcher, other, nsna_ping.target_host);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, nsna_ping.init_wait);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, nsna_ping.interval);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, nsna_ping.missed_max);
|
|
|
|
|
break;
|
|
|
|
|
case LINK_WATCHER_ARP_PING:
|
|
|
|
|
NM_CMP_FIELD_STR(watcher, other, arp_ping.target_host);
|
|
|
|
|
NM_CMP_FIELD_STR(watcher, other, arp_ping.source_host);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, arp_ping.init_wait);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, arp_ping.interval);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, arp_ping.missed_max);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, arp_ping.vlanid);
|
|
|
|
|
NM_CMP_FIELD(watcher, other, arp_ping.flags);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2019-05-11 10:31:57 +02:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 17:13:46 +01:00
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_equal:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
* @other: the #NMTeamLinkWatcher to compare @watcher to.
|
|
|
|
|
*
|
|
|
|
|
* Determines if two #NMTeamLinkWatcher objects contain the same values
|
|
|
|
|
* in all the properties.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the objects contain the same values, %FALSE if they do not.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_equal(const NMTeamLinkWatcher *watcher, const NMTeamLinkWatcher *other)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return nm_team_link_watcher_cmp(watcher, other) == 0;
|
2019-05-11 10:31:57 +02:00
|
|
|
}
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2019-05-11 10:31:57 +02:00
|
|
|
static int
|
2020-09-28 16:03:33 +02:00
|
|
|
_team_link_watchers_cmp_p_with_data(gconstpointer data_a, gconstpointer data_b, gpointer user_data)
|
2019-05-11 10:31:57 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return nm_team_link_watcher_cmp(*((const NMTeamLinkWatcher *const *) data_a),
|
|
|
|
|
*((const NMTeamLinkWatcher *const *) data_b));
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-11 10:31:57 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watchers_cmp(const NMTeamLinkWatcher *const *a,
|
|
|
|
|
const NMTeamLinkWatcher *const *b,
|
|
|
|
|
gsize len,
|
|
|
|
|
gboolean ignore_order)
|
2019-03-21 11:30:21 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
gs_free const NMTeamLinkWatcher **a_free = NULL;
|
|
|
|
|
gs_free const NMTeamLinkWatcher **b_free = NULL;
|
|
|
|
|
guint i;
|
|
|
|
|
|
|
|
|
|
if (ignore_order && len > 1) {
|
|
|
|
|
a = nm_memdup_maybe_a(200, a, len * sizeof(*a), &a_free);
|
|
|
|
|
b = nm_memdup_maybe_a(200, b, len * sizeof(*b), &b_free);
|
|
|
|
|
g_qsort_with_data((gpointer) a, len, sizeof(*a), _team_link_watchers_cmp_p_with_data, NULL);
|
|
|
|
|
g_qsort_with_data((gpointer) b, len, sizeof(*b), _team_link_watchers_cmp_p_with_data, NULL);
|
|
|
|
|
}
|
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
|
NM_CMP_RETURN(nm_team_link_watcher_cmp(a[i], b[i]));
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2019-05-11 10:31:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watchers_equal(const GPtrArray *a, const GPtrArray *b, gboolean ignore_order)
|
2019-05-11 10:31:57 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return a == b
|
|
|
|
|
|| (a && b && a->len == b->len
|
|
|
|
|
&& (nm_team_link_watchers_cmp((const NMTeamLinkWatcher *const *) a->pdata,
|
|
|
|
|
(const NMTeamLinkWatcher *const *) b->pdata,
|
|
|
|
|
a->len,
|
|
|
|
|
ignore_order)
|
|
|
|
|
== 0));
|
2019-03-21 11:30:21 +01:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 17:13:46 +01:00
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_dup:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Creates a copy of @watcher
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): a copy of @watcher
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_dup(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, NULL);
|
|
|
|
|
|
|
|
|
|
switch (watcher->type) {
|
|
|
|
|
case LINK_WATCHER_ETHTOOL:
|
|
|
|
|
return nm_team_link_watcher_new_ethtool(watcher->ethtool.delay_up,
|
|
|
|
|
watcher->ethtool.delay_down,
|
|
|
|
|
NULL);
|
|
|
|
|
break;
|
|
|
|
|
case LINK_WATCHER_NSNA_PING:
|
|
|
|
|
return nm_team_link_watcher_new_nsna_ping(watcher->nsna_ping.init_wait,
|
|
|
|
|
watcher->nsna_ping.interval,
|
|
|
|
|
watcher->nsna_ping.missed_max,
|
|
|
|
|
watcher->nsna_ping.target_host,
|
|
|
|
|
NULL);
|
|
|
|
|
break;
|
|
|
|
|
case LINK_WATCHER_ARP_PING:
|
|
|
|
|
return nm_team_link_watcher_new_arp_ping2(watcher->arp_ping.init_wait,
|
|
|
|
|
watcher->arp_ping.interval,
|
|
|
|
|
watcher->arp_ping.missed_max,
|
|
|
|
|
watcher->arp_ping.vlanid,
|
|
|
|
|
watcher->arp_ping.target_host,
|
|
|
|
|
watcher->arp_ping.source_host,
|
|
|
|
|
watcher->arp_ping.flags,
|
|
|
|
|
NULL);
|
|
|
|
|
default:
|
|
|
|
|
nm_assert_not_reached();
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_name:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the name of the link watcher to be used.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_name(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, NULL);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return _link_watcher_name[watcher->type];
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_delay_up:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the delay_up interval (in milliseconds) that elapses between the link
|
2018-09-15 07:20:54 -04:00
|
|
|
* coming up and the runner being notified about it.
|
2017-11-02 17:13:46 +01:00
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_delay_up(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_ETHTOOL)
|
|
|
|
|
return watcher->ethtool.delay_up;
|
|
|
|
|
return -1;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_delay_down:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the delay_down interval (in milliseconds) that elapses between the link
|
2018-09-15 07:20:54 -04:00
|
|
|
* going down and the runner being notified about it.
|
2017-11-02 17:13:46 +01:00
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_delay_down(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_ETHTOOL)
|
|
|
|
|
return watcher->ethtool.delay_down;
|
|
|
|
|
return -1;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_init_wait:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the init_wait interval (in milliseconds) that the team slave should
|
|
|
|
|
* wait before sending the first packet to the target host.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_init_wait(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_NSNA_PING)
|
|
|
|
|
return watcher->nsna_ping.init_wait;
|
|
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.init_wait;
|
|
|
|
|
return -1;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_interval:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the interval (in milliseconds) that the team slave should wait between
|
|
|
|
|
* sending two check packets to the target host.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_interval(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_NSNA_PING)
|
|
|
|
|
return watcher->nsna_ping.interval;
|
|
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.interval;
|
|
|
|
|
return -1;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_missed_max:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the number of missed replies after which the link is considered down.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_missed_max(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_NSNA_PING)
|
|
|
|
|
return watcher->nsna_ping.missed_max;
|
|
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.missed_max;
|
|
|
|
|
return -1;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
2018-12-05 15:26:50 +01:00
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_vlanid:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the VLAN tag ID to be used to outgoing link probes
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.16
|
|
|
|
|
**/
|
|
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_vlanid(const NMTeamLinkWatcher *watcher)
|
2018-12-05 15:26:50 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, -1);
|
2018-12-05 15:26:50 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.vlanid;
|
|
|
|
|
return -1;
|
2018-12-05 15:26:50 +01:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 17:13:46 +01:00
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_target_host:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the host name/ip address to be used as destination for the link probing
|
|
|
|
|
* packets.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_target_host(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, NULL);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_NSNA_PING)
|
|
|
|
|
return watcher->nsna_ping.target_host;
|
|
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.target_host;
|
|
|
|
|
return NULL;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_source_host:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the ip address to be used as source for the link probing packets.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_source_host(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, NULL);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.source_host;
|
|
|
|
|
return NULL;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_team_link_watcher_get_flags:
|
|
|
|
|
* @watcher: the #NMTeamLinkWatcher
|
|
|
|
|
*
|
|
|
|
|
* Gets the arp ping watcher flags.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcherArpPingFlags
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_link_watcher_get_flags(const NMTeamLinkWatcher *watcher)
|
2017-11-02 17:13:46 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_CHECK_WATCHER(watcher, 0);
|
2017-11-02 17:13:46 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (watcher->type == LINK_WATCHER_ARP_PING)
|
|
|
|
|
return watcher->arp_ping.flags;
|
|
|
|
|
return 0;
|
2017-11-02 17:13:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
static GParamSpec *obj_properties[_NM_TEAM_ATTRIBUTE_MASTER_NUM] = {
|
|
|
|
|
NULL,
|
|
|
|
|
};
|
2017-10-20 11:55:29 +02:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
typedef struct {
|
2020-09-28 16:03:33 +02:00
|
|
|
NMTeamSetting *team_setting;
|
2019-01-11 08:32:54 +01:00
|
|
|
} NMSettingTeamPrivate;
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
G_DEFINE_TYPE(NMSettingTeam, nm_setting_team, NM_TYPE_SETTING)
|
2019-01-11 08:32:54 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#define NM_SETTING_TEAM_GET_PRIVATE(o) \
|
|
|
|
|
(G_TYPE_INSTANCE_GET_PRIVATE((o), NM_TYPE_SETTING_TEAM, NMSettingTeamPrivate))
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm/team: fix handling default values and stricter validate team config
For each artifical team property we need to track whether it was
explicitly set (i.e., present in JSON/GVariant or set by the user
via NMSettingTeam/NMSettingTeamPort API).
--
As a plus, libnm is now no longer concerned with the underling default values
that teamd uses. For example, the effective default value for "notify_peers.count"
depends on the selected runner. But libnm does not need to care, it only cares
wheher the property is set in JSON or not. This also means that the default (e.g. as
interesting to `nmcli -o con show $PROFILE`) is independent from other properties
(like the runner).
Also change the default value for the GObject properties of
NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
For most properties, the default value is a special value that is
not a valid configuration itself.
For some properties the default value is itself a valid value, namely,
"runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
As far as NMTeamSetting is concerned, it distinguishes between unset
value and set value (including the default value). That means,
when it parses a JSON or GVariant, it will remember whether the property
was present or not.
When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
default value, it marks the property as unset. For example, setting
NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
value will not be serialized to JSON/GVariant. For the above 4
properties (where the default value is itself a valid value) this is a
limitation of libnm API, as it does not allow to explicitly set
'"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
Note that changing the default value for properties of NMSetting is problematic,
because it changes behavior for how settings are parsed from keyfile/GVariant.
For team settings that's not the case, because if a JSON "config" is
present, all other properties are ignore. Also, we serialize properties
to JSON/GVariant depending on whether it's marked as present, and not
whether the value is set to the default (_nm_team_settings_property_to_dbus()).
--
While at it, sticter validate the settings. Note that if a setting is
initialized from JSON, the strict validation is not not performed. That
means, such a setting will always validate, regardless whether the values
in JSON are invalid according to libnm. Only when using the extended
properties, strict validation is turned on.
Note that libnm serializes the properties to GVariant both as JSON "config"
and extended properties. Since when parsing a setting from GVariant will
prefer the "config" (if present), in most cases also validation is
performed.
Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
config to disk. When loading a setting from file, strict validation is
also not performed.
The stricter validation only happens if as last operation one of the
artificial properties was set, or if the setting was created from a
GVariant that has no "config" field.
--
This is a (another) change in behavior.
2019-05-31 10:48:47 +02:00
|
|
|
NMTeamSetting *
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_setting_team_get_team_setting(NMSettingTeam *setting)
|
libnm/team: fix handling default values and stricter validate team config
For each artifical team property we need to track whether it was
explicitly set (i.e., present in JSON/GVariant or set by the user
via NMSettingTeam/NMSettingTeamPort API).
--
As a plus, libnm is now no longer concerned with the underling default values
that teamd uses. For example, the effective default value for "notify_peers.count"
depends on the selected runner. But libnm does not need to care, it only cares
wheher the property is set in JSON or not. This also means that the default (e.g. as
interesting to `nmcli -o con show $PROFILE`) is independent from other properties
(like the runner).
Also change the default value for the GObject properties of
NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
For most properties, the default value is a special value that is
not a valid configuration itself.
For some properties the default value is itself a valid value, namely,
"runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
As far as NMTeamSetting is concerned, it distinguishes between unset
value and set value (including the default value). That means,
when it parses a JSON or GVariant, it will remember whether the property
was present or not.
When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
default value, it marks the property as unset. For example, setting
NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
value will not be serialized to JSON/GVariant. For the above 4
properties (where the default value is itself a valid value) this is a
limitation of libnm API, as it does not allow to explicitly set
'"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
Note that changing the default value for properties of NMSetting is problematic,
because it changes behavior for how settings are parsed from keyfile/GVariant.
For team settings that's not the case, because if a JSON "config" is
present, all other properties are ignore. Also, we serialize properties
to JSON/GVariant depending on whether it's marked as present, and not
whether the value is set to the default (_nm_team_settings_property_to_dbus()).
--
While at it, sticter validate the settings. Note that if a setting is
initialized from JSON, the strict validation is not not performed. That
means, such a setting will always validate, regardless whether the values
in JSON are invalid according to libnm. Only when using the extended
properties, strict validation is turned on.
Note that libnm serializes the properties to GVariant both as JSON "config"
and extended properties. Since when parsing a setting from GVariant will
prefer the "config" (if present), in most cases also validation is
performed.
Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
config to disk. When loading a setting from file, strict validation is
also not performed.
The stricter validation only happens if as last operation one of the
artificial properties was set, or if the setting was created from a
GVariant that has no "config" field.
--
This is a (another) change in behavior.
2019-05-31 10:48:47 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting;
|
libnm/team: fix handling default values and stricter validate team config
For each artifical team property we need to track whether it was
explicitly set (i.e., present in JSON/GVariant or set by the user
via NMSettingTeam/NMSettingTeamPort API).
--
As a plus, libnm is now no longer concerned with the underling default values
that teamd uses. For example, the effective default value for "notify_peers.count"
depends on the selected runner. But libnm does not need to care, it only cares
wheher the property is set in JSON or not. This also means that the default (e.g. as
interesting to `nmcli -o con show $PROFILE`) is independent from other properties
(like the runner).
Also change the default value for the GObject properties of
NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
For most properties, the default value is a special value that is
not a valid configuration itself.
For some properties the default value is itself a valid value, namely,
"runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
As far as NMTeamSetting is concerned, it distinguishes between unset
value and set value (including the default value). That means,
when it parses a JSON or GVariant, it will remember whether the property
was present or not.
When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
default value, it marks the property as unset. For example, setting
NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
value will not be serialized to JSON/GVariant. For the above 4
properties (where the default value is itself a valid value) this is a
limitation of libnm API, as it does not allow to explicitly set
'"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
Note that changing the default value for properties of NMSetting is problematic,
because it changes behavior for how settings are parsed from keyfile/GVariant.
For team settings that's not the case, because if a JSON "config" is
present, all other properties are ignore. Also, we serialize properties
to JSON/GVariant depending on whether it's marked as present, and not
whether the value is set to the default (_nm_team_settings_property_to_dbus()).
--
While at it, sticter validate the settings. Note that if a setting is
initialized from JSON, the strict validation is not not performed. That
means, such a setting will always validate, regardless whether the values
in JSON are invalid according to libnm. Only when using the extended
properties, strict validation is turned on.
Note that libnm serializes the properties to GVariant both as JSON "config"
and extended properties. Since when parsing a setting from GVariant will
prefer the "config" (if present), in most cases also validation is
performed.
Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
config to disk. When loading a setting from file, strict validation is
also not performed.
The stricter validation only happens if as last operation one of the
artificial properties was set, or if the setting was created from a
GVariant that has no "config" field.
--
This is a (another) change in behavior.
2019-05-31 10:48:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
#define _maybe_changed(self, changed) \
|
|
|
|
|
nm_team_setting_maybe_changed(NM_SETTING(_NM_ENSURE_TYPE(NMSettingTeam *, self)), \
|
|
|
|
|
(const GParamSpec *const *) obj_properties, \
|
|
|
|
|
(changed))
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
|
|
|
|
#define _maybe_changed_with_assert(self, changed) \
|
2020-09-28 16:03:33 +02:00
|
|
|
G_STMT_START \
|
|
|
|
|
{ \
|
|
|
|
|
if (!_maybe_changed((self), (changed))) \
|
|
|
|
|
nm_assert_not_reached(); \
|
|
|
|
|
} \
|
|
|
|
|
G_STMT_END
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_config:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingTeam:config property of the setting
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_config(NMSettingTeam *setting)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return nm_team_setting_config_get(NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2017-10-12 12:02:06 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_notify_peers_count:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:notify-peers-count property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_notify_peers_count(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.notify_peers_count;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_notify_peers_interval:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:notify-peers-interval property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_notify_peers_interval(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.notify_peers_interval;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_mcast_rejoin_count:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:mcast-rejoin-count property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_mcast_rejoin_count(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.mcast_rejoin_count;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_mcast_rejoin_interval:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:mcast-rejoin-interval property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_mcast_rejoin_interval(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.mcast_rejoin_interval;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_hwaddr_policy:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-hwaddr-policy property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_hwaddr_policy(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_hwaddr_policy;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_tx_balancer:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-tx-balancer property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_tx_balancer(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_tx_balancer;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_tx_balancer_interval:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-tx-balancer_interval property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_tx_balancer_interval(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_tx_balancer_interval;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_active:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner_active property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_active(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_active;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_fast_rate:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-fast-rate property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_fast_rate(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_fast_rate;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_sys_prio:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-sys-prio property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_sys_prio(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_sys_prio;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_min_ports:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-min-ports property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_min_ports(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_min_ports;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_agg_select_policy:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the ##NMSettingTeam:runner-agg-select-policy property of the setting
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_agg_select_policy(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_agg_select_policy;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_remove_runner_tx_hash_by_value:
|
|
|
|
|
* @setting: the #NMSetetingTeam
|
|
|
|
|
* @txhash: the txhash element to remove
|
|
|
|
|
*
|
|
|
|
|
* Removes the txhash element #txhash
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the txhash element was found and removed; %FALSE if it was not.
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_remove_runner_tx_hash_by_value(NMSettingTeam *setting, const char *txhash)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
|
|
|
|
const GPtrArray * arr;
|
|
|
|
|
guint i;
|
|
|
|
|
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
|
|
|
|
g_return_val_if_fail(txhash != NULL, FALSE);
|
|
|
|
|
|
|
|
|
|
arr = priv->team_setting->d.master.runner_tx_hash;
|
|
|
|
|
if (arr) {
|
|
|
|
|
for (i = 0; i < arr->len; i++) {
|
|
|
|
|
if (nm_streq(txhash, arr->pdata[i])) {
|
|
|
|
|
_maybe_changed_with_assert(
|
|
|
|
|
setting,
|
|
|
|
|
nm_team_setting_value_master_runner_tx_hash_remove(priv->team_setting, i));
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return FALSE;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_num_runner_tx_hash:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the number of elements in txhash
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
guint
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_num_runner_tx_hash(NMSettingTeam *setting)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
const GPtrArray *arr;
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
arr = NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_tx_hash;
|
|
|
|
|
return arr ? arr->len : 0u;
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_runner_tx_hash
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @idx: index number of the txhash element to return
|
|
|
|
|
*
|
|
|
|
|
* Returns: the txhash element at index @idx
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
const char *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_runner_tx_hash(NMSettingTeam *setting, guint idx)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
const GPtrArray *arr;
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
arr = NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.master.runner_tx_hash;
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(arr, NULL);
|
|
|
|
|
g_return_val_if_fail(idx < arr->len, NULL);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return arr->pdata[idx];
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_remove_runner_tx_hash:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @idx: index number of the element to remove from txhash
|
|
|
|
|
*
|
|
|
|
|
* Removes the txhash element at index @idx.
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_remove_runner_tx_hash(NMSettingTeam *setting, guint idx)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv;
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_if_fail(NM_IS_SETTING_TEAM(setting));
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_if_fail(priv->team_setting->d.master.runner_tx_hash);
|
|
|
|
|
g_return_if_fail(idx < priv->team_setting->d.master.runner_tx_hash->len);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
_maybe_changed_with_assert(
|
|
|
|
|
setting,
|
|
|
|
|
nm_team_setting_value_master_runner_tx_hash_remove(priv->team_setting, idx));
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_add_runner_tx_hash:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @txhash: the element to add to txhash
|
|
|
|
|
*
|
|
|
|
|
* Adds a new txhash element to the setting.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the txhash element was added; %FALSE if the element
|
|
|
|
|
* was already knnown.
|
|
|
|
|
*
|
2017-11-10 12:15:39 +01:00
|
|
|
* Since: 1.12
|
2017-10-12 12:02:06 +02:00
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_add_runner_tx_hash(NMSettingTeam *setting, const char *txhash)
|
2017-10-12 12:02:06 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
|
|
|
|
g_return_val_if_fail(txhash, FALSE);
|
2017-10-12 12:02:06 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return _maybe_changed(setting,
|
|
|
|
|
nm_team_setting_value_master_runner_tx_hash_add(
|
|
|
|
|
NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting,
|
|
|
|
|
txhash));
|
2017-10-12 12:02:06 +02:00
|
|
|
}
|
|
|
|
|
|
2017-11-06 15:47:32 +01:00
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_num_link_watchers:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Returns: the number of configured link watchers
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
guint
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_num_link_watchers(NMSettingTeam *setting)
|
2017-11-06 15:47:32 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), 0);
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.link_watchers->len;
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_get_link_watcher:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @idx: index number of the link watcher to return
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer none): the link watcher at index @idx.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMTeamLinkWatcher *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_get_link_watcher(NMSettingTeam *setting, guint idx)
|
2017-11-06 15:47:32 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
const GPtrArray *arr;
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), NULL);
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
arr = NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting->d.link_watchers;
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(idx < arr->len, NULL);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return arr->pdata[idx];
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_add_link_watcher:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @link_watcher: the link watcher to add
|
|
|
|
|
*
|
|
|
|
|
* Appends a new link watcher to the setting.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the link watcher is added; %FALSE if an identical link
|
|
|
|
|
* watcher was already there.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_add_link_watcher(NMSettingTeam *setting, NMTeamLinkWatcher *link_watcher)
|
2017-11-06 15:47:32 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
|
|
|
|
g_return_val_if_fail(link_watcher != NULL, FALSE);
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return _maybe_changed(
|
|
|
|
|
setting,
|
|
|
|
|
nm_team_setting_value_link_watchers_add(NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting,
|
|
|
|
|
link_watcher));
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_remove_link_watcher:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @idx: index number of the link watcher to remove
|
|
|
|
|
*
|
|
|
|
|
* Removes the link watcher at index #idx.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_remove_link_watcher(NMSettingTeam *setting, guint idx)
|
2017-11-06 15:47:32 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv;
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_if_fail(NM_IS_SETTING_TEAM(setting));
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_if_fail(idx < priv->team_setting->d.link_watchers->len);
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
_maybe_changed_with_assert(setting,
|
|
|
|
|
nm_team_setting_value_link_watchers_remove(priv->team_setting, idx));
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_remove_link_watcher_by_value:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
* @link_watcher: the link watcher to remove
|
|
|
|
|
*
|
|
|
|
|
* Removes the link watcher entry matching link_watcher.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the link watcher was found and removed, %FALSE otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_remove_link_watcher_by_value(NMSettingTeam * setting,
|
|
|
|
|
NMTeamLinkWatcher *link_watcher)
|
2017-11-06 15:47:32 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_TEAM(setting), FALSE);
|
|
|
|
|
g_return_val_if_fail(link_watcher, FALSE);
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return _maybe_changed(setting,
|
|
|
|
|
nm_team_setting_value_link_watchers_remove_by_value(
|
|
|
|
|
NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting,
|
|
|
|
|
link_watcher));
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_clear_link_watchers:
|
|
|
|
|
* @setting: the #NMSettingTeam
|
|
|
|
|
*
|
|
|
|
|
* Removes all configured link watchers.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_clear_link_watchers(NMSettingTeam *setting)
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
g_return_if_fail(NM_IS_SETTING_TEAM(setting));
|
2017-11-06 15:47:32 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
_maybe_changed(setting,
|
|
|
|
|
nm_team_setting_value_link_watchers_set_list(
|
|
|
|
|
NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting,
|
|
|
|
|
NULL,
|
|
|
|
|
0));
|
2017-11-06 15:47:32 +01:00
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
verify(NMSetting *setting, NMConnection *connection, GError **error)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
2016-03-11 13:17:24 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (!_nm_connection_verify_required_interface_name(connection, error))
|
|
|
|
|
return FALSE;
|
2016-03-11 13:17:24 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
if (!nm_team_setting_verify(priv->team_setting, error))
|
|
|
|
|
return FALSE;
|
2016-08-30 16:37:54 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
return TRUE;
|
2016-03-11 13:17:24 +01:00
|
|
|
}
|
|
|
|
|
|
libnm: rework compare_property() implementation for NMSetting
NMSetting's compare_property() has and had two callers:
nm_setting_compare() and nm_setting_diff().
compare_property() accepts a NMSettingCompareFlags argument, but
at the same time, both callers have another complex (and
inconsistent!) set of pre-checks for shortcuting the call of
compare_property(): should_compare_prop().
Merge should_compare_prop() into compare_property(). This way,
nm_setting_compare() and nm_setting_diff() has less additional
code, and are simpler to follow. Especially nm_setting_compare()
is now trivial. And nm_setting_diff() is still complicated, but
not related to the question how the property compares or whether
it should be compared at all.
If you want to know whether it should be compared, all you need to do
now is follow NMSettingClass.compare_property().
This changes function pointer NMSettingClass.compare_property(),
which is public API. However, no user can actually use this (and shall
not!), because _nm_setting_class_commit_full() etc. is private API. A
user outside of libnm-core cannot create his/her own subclasses of
NMSetting, and never could in the past. So, this API/ABI change doesn't
matter.
2019-01-09 09:08:39 +01:00
|
|
|
static NMTernary
|
2020-09-28 16:03:33 +02:00
|
|
|
compare_property(const NMSettInfoSetting *sett_info,
|
|
|
|
|
guint property_idx,
|
|
|
|
|
NMConnection * con_a,
|
|
|
|
|
NMSetting * set_a,
|
|
|
|
|
NMConnection * con_b,
|
|
|
|
|
NMSetting * set_b,
|
|
|
|
|
NMSettingCompareFlags flags)
|
2016-03-11 13:17:24 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *a_priv, *b_priv;
|
|
|
|
|
|
|
|
|
|
if (nm_streq(sett_info->property_infos[property_idx].name, NM_SETTING_TEAM_LINK_WATCHERS)) {
|
|
|
|
|
if (NM_FLAGS_HAS(flags, NM_SETTING_COMPARE_FLAG_INFERRABLE))
|
|
|
|
|
return NM_TERNARY_DEFAULT;
|
|
|
|
|
if (!set_b)
|
|
|
|
|
return TRUE;
|
|
|
|
|
a_priv = NM_SETTING_TEAM_GET_PRIVATE(set_a);
|
|
|
|
|
b_priv = NM_SETTING_TEAM_GET_PRIVATE(set_b);
|
|
|
|
|
return nm_team_link_watchers_equal(a_priv->team_setting->d.link_watchers,
|
|
|
|
|
b_priv->team_setting->d.link_watchers,
|
|
|
|
|
TRUE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nm_streq(sett_info->property_infos[property_idx].name, NM_SETTING_TEAM_CONFIG)) {
|
|
|
|
|
if (set_b) {
|
|
|
|
|
if (NM_FLAGS_HAS(flags, NM_SETTING_COMPARE_FLAG_INFERRABLE)) {
|
|
|
|
|
/* If we are trying to match a connection in order to assume it (and thus
|
2020-09-28 14:50:01 +02:00
|
|
|
* @flags contains INFERRABLE), use the "relaxed" matching for team
|
|
|
|
|
* configuration. Otherwise, for all other purposes (including connection
|
|
|
|
|
* comparison before an update), resort to the default string comparison. */
|
2020-09-28 16:03:33 +02:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
a_priv = NM_SETTING_TEAM_GET_PRIVATE(set_a);
|
|
|
|
|
b_priv = NM_SETTING_TEAM_GET_PRIVATE(set_b);
|
|
|
|
|
|
|
|
|
|
return nm_streq0(nm_team_setting_config_get(a_priv->team_setting),
|
|
|
|
|
nm_team_setting_config_get(b_priv->team_setting));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CLASS(nm_setting_team_parent_class)
|
|
|
|
|
->compare_property(sett_info, property_idx, con_a, set_a, con_b, set_b, flags);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2017-10-20 11:55:29 +02:00
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
duplicate_copy_properties(const NMSettInfoSetting *sett_info, NMSetting *src, NMSetting *dst)
|
2017-10-20 11:55:29 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
_maybe_changed(NM_SETTING_TEAM(dst),
|
|
|
|
|
nm_team_setting_reset(NM_SETTING_TEAM_GET_PRIVATE(dst)->team_setting,
|
|
|
|
|
NM_SETTING_TEAM_GET_PRIVATE(src)->team_setting));
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
2020-09-28 16:03:33 +02:00
|
|
|
init_from_dbus(NMSetting * setting,
|
|
|
|
|
GHashTable * keys,
|
|
|
|
|
GVariant * setting_dict,
|
|
|
|
|
GVariant * connection_dict,
|
|
|
|
|
guint /* NMSettingParseFlags */ parse_flags,
|
|
|
|
|
GError ** error)
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 12:36:41 +02:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
guint32 changed = 0;
|
|
|
|
|
gboolean success;
|
|
|
|
|
|
|
|
|
|
if (keys)
|
|
|
|
|
g_hash_table_remove(keys, "interface-name");
|
|
|
|
|
|
|
|
|
|
success = nm_team_setting_reset_from_dbus(NM_SETTING_TEAM_GET_PRIVATE(setting)->team_setting,
|
|
|
|
|
setting_dict,
|
|
|
|
|
keys,
|
|
|
|
|
&changed,
|
|
|
|
|
parse_flags,
|
|
|
|
|
error);
|
|
|
|
|
_maybe_changed(NM_SETTING_TEAM(setting), changed);
|
|
|
|
|
return success;
|
2017-10-20 11:55:29 +02:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
|
2019-01-11 08:32:54 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeam * setting = NM_SETTING_TEAM(object);
|
|
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
|
|
|
|
const GPtrArray * v_ptrarr;
|
|
|
|
|
|
|
|
|
|
switch (prop_id) {
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_CONFIG:
|
|
|
|
|
g_value_set_string(value, nm_team_setting_config_get(priv->team_setting));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_ACTIVE:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_FAST_RATE:
|
|
|
|
|
g_value_set_boolean(value, nm_team_setting_value_get_bool(priv->team_setting, prop_id));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_COUNT:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_COUNT:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_SYS_PRIO:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_MIN_PORTS:
|
|
|
|
|
g_value_set_int(value, nm_team_setting_value_get_int32(priv->team_setting, prop_id));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_HWADDR_POLICY:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_AGG_SELECT_POLICY:
|
|
|
|
|
g_value_set_string(value, nm_team_setting_value_get_string(priv->team_setting, prop_id));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_HASH:
|
|
|
|
|
v_ptrarr = priv->team_setting->d.master.runner_tx_hash;
|
|
|
|
|
g_value_take_boxed(value,
|
|
|
|
|
v_ptrarr ? _nm_utils_ptrarray_to_strv((GPtrArray *) v_ptrarr) : NULL);
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_LINK_WATCHERS:
|
|
|
|
|
g_value_take_boxed(value,
|
|
|
|
|
_nm_utils_copy_array(priv->team_setting->d.link_watchers,
|
|
|
|
|
(NMUtilsCopyFunc) _nm_team_link_watcher_ref,
|
|
|
|
|
(GDestroyNotify) nm_team_link_watcher_unref));
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
set_property(GObject *object, guint prop_id, const GValue *value, GParamSpec *pspec)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeam * setting = NM_SETTING_TEAM(object);
|
|
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(object);
|
|
|
|
|
guint32 changed;
|
|
|
|
|
const GPtrArray * v_ptrarr;
|
|
|
|
|
|
|
|
|
|
switch (prop_id) {
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_CONFIG:
|
|
|
|
|
changed = nm_team_setting_config_set(priv->team_setting, g_value_get_string(value));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_ACTIVE:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_FAST_RATE:
|
|
|
|
|
changed =
|
|
|
|
|
nm_team_setting_value_set_bool(priv->team_setting, prop_id, g_value_get_boolean(value));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_COUNT:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_COUNT:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER_INTERVAL:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_SYS_PRIO:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_MIN_PORTS:
|
|
|
|
|
changed =
|
|
|
|
|
nm_team_setting_value_set_int32(priv->team_setting, prop_id, g_value_get_int(value));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_HWADDR_POLICY:
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_AGG_SELECT_POLICY:
|
|
|
|
|
changed = nm_team_setting_value_set_string(priv->team_setting,
|
|
|
|
|
prop_id,
|
|
|
|
|
g_value_get_string(value));
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_HASH:
|
|
|
|
|
v_ptrarr = g_value_get_boxed(value);
|
|
|
|
|
changed = nm_team_setting_value_master_runner_tx_hash_set_list(
|
|
|
|
|
priv->team_setting,
|
|
|
|
|
v_ptrarr ? (const char *const *) v_ptrarr->pdata : NULL,
|
|
|
|
|
v_ptrarr ? v_ptrarr->len : 0u);
|
|
|
|
|
break;
|
|
|
|
|
case NM_TEAM_ATTRIBUTE_LINK_WATCHERS:
|
|
|
|
|
v_ptrarr = g_value_get_boxed(value);
|
|
|
|
|
changed = nm_team_setting_value_link_watchers_set_list(
|
|
|
|
|
priv->team_setting,
|
|
|
|
|
v_ptrarr ? (const NMTeamLinkWatcher *const *) v_ptrarr->pdata : NULL,
|
|
|
|
|
v_ptrarr ? v_ptrarr->len : 0u);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
_maybe_changed(setting, changed & ~(((guint32) 1) << prop_id));
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_init(NMSettingTeam *setting)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
priv->team_setting = nm_team_setting_new(FALSE, NULL);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_team_new:
|
|
|
|
|
*
|
|
|
|
|
* Creates a new #NMSettingTeam object with default values.
|
|
|
|
|
*
|
|
|
|
|
* Returns: (transfer full): the new empty #NMSettingTeam object
|
|
|
|
|
**/
|
|
|
|
|
NMSetting *
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_new(void)
|
2019-01-11 08:32:54 +01:00
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_SETTING_TEAM, NULL);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
finalize(GObject *object)
|
2019-01-11 08:32:54 +01:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
NMSettingTeamPrivate *priv = NM_SETTING_TEAM_GET_PRIVATE(object);
|
2019-01-11 08:32:54 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_team_setting_free(priv->team_setting);
|
2019-01-11 08:32:54 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
G_OBJECT_CLASS(nm_setting_team_parent_class)->finalize(object);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-09-28 16:03:33 +02:00
|
|
|
nm_setting_team_class_init(NMSettingTeamClass *klass)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-09-28 16:03:33 +02:00
|
|
|
GObjectClass * object_class = G_OBJECT_CLASS(klass);
|
|
|
|
|
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
|
|
|
|
|
GArray * properties_override = _nm_sett_info_property_override_create_array();
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_type_class_add_private(klass, sizeof(NMSettingTeamPrivate));
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
object_class->get_property = get_property;
|
|
|
|
|
object_class->set_property = set_property;
|
|
|
|
|
object_class->finalize = finalize;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
setting_class->compare_property = compare_property;
|
|
|
|
|
setting_class->verify = verify;
|
|
|
|
|
setting_class->duplicate_copy_properties = duplicate_copy_properties;
|
|
|
|
|
setting_class->init_from_dbus = init_from_dbus;
|
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
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:config:
|
|
|
|
|
*
|
|
|
|
|
* The JSON configuration for the team network interface. The property
|
|
|
|
|
* should contain raw JSON configuration data suitable for teamd, because
|
|
|
|
|
* the value is passed directly to teamd. If not specified, the default
|
|
|
|
|
* configuration is used. See man teamd.conf for the format details.
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
/* ---ifcfg-rh---
|
2020-09-28 14:50:01 +02:00
|
|
|
* property: config
|
|
|
|
|
* variable: TEAM_CONFIG
|
|
|
|
|
* description: Team configuration in JSON. See man teamd.conf for details.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_CONFIG] = g_param_spec_string(
|
|
|
|
|
NM_SETTING_TEAM_CONFIG,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NULL,
|
|
|
|
|
G_PARAM_READWRITE | NM_SETTING_PARAM_INFERRABLE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_CONFIG],
|
|
|
|
|
&nm_sett_info_propert_type_team_s);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:notify-peers-count:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd notify_peers.count.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_COUNT] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_NOTIFY_PEERS_COUNT,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_COUNT],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:notify-peers-interval:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd notify_peers.interval.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_INTERVAL] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_NOTIFY_PEERS_INTERVAL,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_NOTIFY_PEERS_INTERVAL],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:mcast-rejoin-count:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd mcast_rejoin.count.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_COUNT] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_MCAST_REJOIN_COUNT,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_COUNT],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:mcast-rejoin-interval:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd mcast_rejoin.interval.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_INTERVAL] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_MCAST_REJOIN_INTERVAL,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_MCAST_REJOIN_INTERVAL],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.name.
|
|
|
|
|
* Permitted values are: "roundrobin", "broadcast", "activebackup",
|
|
|
|
|
* "loadbalance", "lacp", "random".
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER] =
|
|
|
|
|
g_param_spec_string(NM_SETTING_TEAM_RUNNER,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NULL,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER],
|
|
|
|
|
&nm_sett_info_propert_type_team_s);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-hwaddr-policy:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.hwaddr_policy.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_HWADDR_POLICY] =
|
|
|
|
|
g_param_spec_string(NM_SETTING_TEAM_RUNNER_HWADDR_POLICY,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NULL,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_HWADDR_POLICY],
|
|
|
|
|
&nm_sett_info_propert_type_team_s);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-tx-hash:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.tx_hash.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_HASH] = g_param_spec_boxed(
|
|
|
|
|
NM_SETTING_TEAM_RUNNER_TX_HASH,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_TYPE_STRV,
|
|
|
|
|
G_PARAM_READWRITE | NM_SETTING_PARAM_INFERRABLE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_HASH],
|
|
|
|
|
&nm_sett_info_propert_type_team_as);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-tx-balancer:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.tx_balancer.name.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER] =
|
|
|
|
|
g_param_spec_string(NM_SETTING_TEAM_RUNNER_TX_BALANCER,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NULL,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER],
|
|
|
|
|
&nm_sett_info_propert_type_team_s);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-tx-balancer-interval:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.tx_balancer.interval.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER_INTERVAL] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_RUNNER_TX_BALANCER_INTERVAL,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(
|
|
|
|
|
properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_TX_BALANCER_INTERVAL],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-active:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.active.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_ACTIVE] =
|
|
|
|
|
g_param_spec_boolean(NM_SETTING_TEAM_RUNNER_ACTIVE,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
TRUE,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_ACTIVE],
|
|
|
|
|
&nm_sett_info_propert_type_team_b);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-fast-rate:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.fast_rate.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_FAST_RATE] =
|
|
|
|
|
g_param_spec_boolean(NM_SETTING_TEAM_RUNNER_FAST_RATE,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
FALSE,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_FAST_RATE],
|
|
|
|
|
&nm_sett_info_propert_type_team_b);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-sys-prio:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.sys_prio.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_SYS_PRIO] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_RUNNER_SYS_PRIO,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_SYS_PRIO],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-min-ports:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.min_ports.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_MIN_PORTS] =
|
|
|
|
|
g_param_spec_int(NM_SETTING_TEAM_RUNNER_MIN_PORTS,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_MIN_PORTS],
|
|
|
|
|
&nm_sett_info_propert_type_team_i);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:runner-agg-select-policy:
|
|
|
|
|
*
|
|
|
|
|
* Corresponds to the teamd runner.agg_select_policy.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_AGG_SELECT_POLICY] =
|
|
|
|
|
g_param_spec_string(NM_SETTING_TEAM_RUNNER_AGG_SELECT_POLICY,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
NULL,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_MASTER_RUNNER_AGG_SELECT_POLICY],
|
|
|
|
|
&nm_sett_info_propert_type_team_s);
|
|
|
|
|
|
|
|
|
|
/**
|
2020-09-28 14:50:01 +02:00
|
|
|
* NMSettingTeam:link-watchers: (type GPtrArray(NMTeamLinkWatcher))
|
|
|
|
|
*
|
|
|
|
|
* Link watchers configuration for the connection: each link watcher is
|
|
|
|
|
* defined by a dictionary, whose keys depend upon the selected link
|
|
|
|
|
* watcher. Available link watchers are 'ethtool', 'nsna_ping' and
|
|
|
|
|
* 'arp_ping' and it is specified in the dictionary with the key 'name'.
|
|
|
|
|
* Available keys are: ethtool: 'delay-up', 'delay-down', 'init-wait';
|
|
|
|
|
* nsna_ping: 'init-wait', 'interval', 'missed-max', 'target-host';
|
|
|
|
|
* arp_ping: all the ones in nsna_ping and 'source-host', 'validate-active',
|
|
|
|
|
* 'validate-inactive', 'send-always'. See teamd.conf man for more details.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
2020-09-28 16:03:33 +02:00
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_LINK_WATCHERS] =
|
|
|
|
|
g_param_spec_boxed(NM_SETTING_TEAM_LINK_WATCHERS,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
G_TYPE_PTR_ARRAY,
|
|
|
|
|
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS);
|
|
|
|
|
_nm_properties_override_gobj(properties_override,
|
|
|
|
|
obj_properties[NM_TEAM_ATTRIBUTE_LINK_WATCHERS],
|
|
|
|
|
&nm_sett_info_propert_type_team_link_watchers);
|
|
|
|
|
|
|
|
|
|
/* ---dbus---
|
2020-09-28 14:50:01 +02:00
|
|
|
* property: interface-name
|
|
|
|
|
* format: string
|
|
|
|
|
* description: Deprecated in favor of connection.interface-name, but can
|
|
|
|
|
* be used for backward-compatibility with older daemons, to set the
|
|
|
|
|
* team's interface name.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_properties_override_dbus(properties_override,
|
|
|
|
|
"interface-name",
|
|
|
|
|
&nm_sett_info_propert_type_deprecated_interface_name);
|
libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.
Rework the tracking of the list, so that:
- instead of attaching the data to the GType of the setting via
g_type_set_qdata(), it is tracked in a static array indexed by
NMMetaSettingType. This allows to find the setting-data by simple
pointer arithmetic, instead of taking a look and iterating (like
g_type_set_qdata() does).
Note, that this is still thread safe, because the static table entry is
initialized in the class-init function with _nm_setting_class_commit().
And it only accessed by following a NMSettingClass instance, thus
the class constructor already ran (maybe not for all setting classes,
but for the particular one that we look up).
I think this makes initialization of the metadata simpler to
understand.
Previously, in a first phase each class would attach the metadata
to the GType as setting_property_overrides_quark(). Then during
nm_setting_class_ensure_properties() it would merge them and
set as setting_properties_quark(). Now, during the first phase,
we only incrementally build a properties_override GArray, which
we finally hand over during nm_setting_class_commit().
- sort the property infos by name and do binary search.
Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.
Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-07-28 15:26:03 +02:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
g_object_class_install_properties(object_class, G_N_ELEMENTS(obj_properties), obj_properties);
|
2019-01-11 08:28:26 +01:00
|
|
|
|
2020-09-28 16:03:33 +02:00
|
|
|
_nm_setting_class_commit_full(setting_class,
|
|
|
|
|
NM_META_SETTING_TYPE_TEAM,
|
|
|
|
|
NULL,
|
|
|
|
|
properties_override);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|