2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2013 Jiri Pirko <jiri@resnulli.us>
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
all: fix up multiple-include-guard defines
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
2014-08-13 14:10:11 -04:00
|
|
|
#ifndef __NM_SETTING_TEAM_PORT_H__
|
|
|
|
|
#define __NM_SETTING_TEAM_PORT_H__
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2014-07-06 16:53:02 -04:00
|
|
|
#if !defined(__NETWORKMANAGER_H_INSIDE__) && !defined(NETWORKMANAGER_COMPILATION)
|
|
|
|
|
#error "Only <NetworkManager.h> can be included directly."
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-03-09 13:02:20 +01:00
|
|
|
#include "nm-setting.h"
|
2017-11-16 18:54:06 +01:00
|
|
|
#include "nm-setting-team.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
|
|
|
|
|
#define NM_TYPE_SETTING_TEAM_PORT (nm_setting_team_port_get_type())
|
|
|
|
|
#define NM_SETTING_TEAM_PORT(obj) \
|
|
|
|
|
(G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_SETTING_TEAM_PORT, NMSettingTeamPort))
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_CLASS(klass) \
|
|
|
|
|
(G_TYPE_CHECK_CLASS_CAST((klass), NM_TYPE_SETTING_TEAM_PORT, NMSettingTeamPortClass))
|
|
|
|
|
#define NM_IS_SETTING_TEAM_PORT(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj), NM_TYPE_SETTING_TEAM_PORT))
|
|
|
|
|
#define NM_IS_SETTING_TEAM_PORT_CLASS(klass) \
|
|
|
|
|
(G_TYPE_CHECK_CLASS_TYPE((klass), NM_TYPE_SETTING_TEAM_PORT))
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_GET_CLASS(obj) \
|
|
|
|
|
(G_TYPE_INSTANCE_GET_CLASS((obj), NM_TYPE_SETTING_TEAM_PORT, NMSettingTeamPortClass))
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_SETTING_NAME "team-port"
|
|
|
|
|
|
2017-11-16 18:54:06 +01:00
|
|
|
#define NM_SETTING_TEAM_PORT_CONFIG "config"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_QUEUE_ID "queue-id"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_PRIO "prio"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_STICKY "sticky"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_LACP_PRIO "lacp-prio"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_LACP_KEY "lacp-key"
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_LINK_WATCHERS "link-watchers"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2017-11-08 18:10:27 +01:00
|
|
|
#define NM_SETTING_TEAM_PORT_QUEUE_ID_DEFAULT -1
|
|
|
|
|
#define NM_SETTING_TEAM_PORT_LACP_PRIO_DEFAULT 255
|
|
|
|
|
|
2016-05-05 09:36:32 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingTeamPort:
|
2017-03-10 20:04:34 +01:00
|
|
|
*
|
|
|
|
|
* Team Port Settings
|
2016-05-05 09:36:32 +02:00
|
|
|
*/
|
2014-10-21 22:09:52 -04:00
|
|
|
struct _NMSettingTeamPort {
|
2014-07-24 08:53:33 -04:00
|
|
|
NMSetting parent;
|
2014-10-21 22:09:52 -04:00
|
|
|
};
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
NMSettingClass parent;
|
|
|
|
|
|
2014-05-15 09:55:18 -04:00
|
|
|
/*< private >*/
|
|
|
|
|
gpointer padding[4];
|
2014-07-24 08:53:33 -04:00
|
|
|
} NMSettingTeamPortClass;
|
|
|
|
|
|
|
|
|
|
GType nm_setting_team_port_get_type(void);
|
|
|
|
|
|
|
|
|
|
NMSetting *nm_setting_team_port_new(void);
|
|
|
|
|
|
|
|
|
|
const char *nm_setting_team_port_get_config(NMSettingTeamPort *setting);
|
2017-10-30 12:27:58 +01:00
|
|
|
NM_AVAILABLE_IN_1_12
|
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 nm_setting_team_port_get_queue_id(NMSettingTeamPort *setting);
|
2017-10-30 12:27:58 +01:00
|
|
|
NM_AVAILABLE_IN_1_12
|
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 nm_setting_team_port_get_prio(NMSettingTeamPort *setting);
|
2017-10-30 12:27:58 +01:00
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
gboolean nm_setting_team_port_get_sticky(NMSettingTeamPort *setting);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
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 nm_setting_team_port_get_lacp_prio(NMSettingTeamPort *setting);
|
2017-10-30 12:27:58 +01:00
|
|
|
NM_AVAILABLE_IN_1_12
|
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 nm_setting_team_port_get_lacp_key(NMSettingTeamPort *setting);
|
2017-11-16 18:54:06 +01:00
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
guint nm_setting_team_port_get_num_link_watchers(NMSettingTeamPort *setting);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
NMTeamLinkWatcher *nm_setting_team_port_get_link_watcher(NMSettingTeamPort *setting, guint idx);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
gboolean nm_setting_team_port_add_link_watcher(NMSettingTeamPort *setting,
|
|
|
|
|
NMTeamLinkWatcher *link_watcher);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
void nm_setting_team_port_remove_link_watcher(NMSettingTeamPort *setting, guint idx);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
gboolean nm_setting_team_port_remove_link_watcher_by_value(NMSettingTeamPort *setting,
|
|
|
|
|
NMTeamLinkWatcher *link_watcher);
|
|
|
|
|
NM_AVAILABLE_IN_1_12
|
|
|
|
|
void nm_setting_team_port_clear_link_watchers(NMSettingTeamPort *setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
G_END_DECLS
|
|
|
|
|
|
all: fix up multiple-include-guard defines
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
2014-08-13 14:10:11 -04:00
|
|
|
#endif /* __NM_SETTING_TEAM_PORT_H__ */
|