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) 2013 Red Hat, Inc.
|
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_DCB_H__
|
|
|
|
|
#define __NM_SETTING_DCB_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"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
|
|
|
|
|
#define NM_TYPE_SETTING_DCB (nm_setting_dcb_get_type())
|
|
|
|
|
#define NM_SETTING_DCB(obj) (G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_SETTING_DCB, NMSettingDcb))
|
|
|
|
|
#define NM_SETTING_DCB_CLASS(klass) \
|
|
|
|
|
(G_TYPE_CHECK_CLASS_CAST((klass), NM_TYPE_SETTING_DCB, NMSettingDcbClass))
|
|
|
|
|
#define NM_IS_SETTING_DCB(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj), NM_TYPE_SETTING_DCB))
|
|
|
|
|
#define NM_IS_SETTING_DCB_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE((klass), NM_TYPE_SETTING_DCB))
|
|
|
|
|
#define NM_SETTING_DCB_GET_CLASS(obj) \
|
|
|
|
|
(G_TYPE_INSTANCE_GET_CLASS((obj), NM_TYPE_SETTING_DCB, NMSettingDcbClass))
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_DCB_SETTING_NAME "dcb"
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMSettingDcbFlags:
|
|
|
|
|
* @NM_SETTING_DCB_FLAG_NONE: no flag
|
|
|
|
|
* @NM_SETTING_DCB_FLAG_ENABLE: the feature is enabled
|
|
|
|
|
* @NM_SETTING_DCB_FLAG_ADVERTISE: the feature is advertised
|
|
|
|
|
* @NM_SETTING_DCB_FLAG_WILLING: the feature is willing to change based on
|
|
|
|
|
* peer configuration advertisements
|
|
|
|
|
*
|
|
|
|
|
* DCB feature flags.
|
|
|
|
|
**/
|
2014-06-26 16:47:46 -04:00
|
|
|
typedef enum { /*< flags >*/
|
2014-07-24 08:53:33 -04:00
|
|
|
NM_SETTING_DCB_FLAG_NONE = 0x00000000,
|
|
|
|
|
NM_SETTING_DCB_FLAG_ENABLE = 0x00000001,
|
|
|
|
|
NM_SETTING_DCB_FLAG_ADVERTISE = 0x00000002,
|
|
|
|
|
NM_SETTING_DCB_FLAG_WILLING = 0x00000004
|
|
|
|
|
} NMSettingDcbFlags;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NM_SETTING_DCB_FCOE_MODE_FABRIC:
|
|
|
|
|
*
|
|
|
|
|
* Indicates that the FCoE controller should use "fabric" mode (default)
|
|
|
|
|
*/
|
|
|
|
|
#define NM_SETTING_DCB_FCOE_MODE_FABRIC "fabric"
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NM_SETTING_DCB_FCOE_MODE_VN2VN:
|
|
|
|
|
*
|
|
|
|
|
* Indicates that the FCoE controller should use "VN2VN" mode.
|
|
|
|
|
*/
|
|
|
|
|
#define NM_SETTING_DCB_FCOE_MODE_VN2VN "vn2vn"
|
|
|
|
|
|
|
|
|
|
/* Properties */
|
|
|
|
|
#define NM_SETTING_DCB_APP_FCOE_FLAGS "app-fcoe-flags"
|
|
|
|
|
#define NM_SETTING_DCB_APP_FCOE_PRIORITY "app-fcoe-priority"
|
|
|
|
|
#define NM_SETTING_DCB_APP_FCOE_MODE "app-fcoe-mode"
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_DCB_APP_ISCSI_FLAGS "app-iscsi-flags"
|
|
|
|
|
#define NM_SETTING_DCB_APP_ISCSI_PRIORITY "app-iscsi-priority"
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_DCB_APP_FIP_FLAGS "app-fip-flags"
|
|
|
|
|
#define NM_SETTING_DCB_APP_FIP_PRIORITY "app-fip-priority"
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_FLOW_CONTROL_FLAGS "priority-flow-control-flags"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_FLOW_CONTROL "priority-flow-control"
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_GROUP_FLAGS "priority-group-flags"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_GROUP_ID "priority-group-id"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_GROUP_BANDWIDTH "priority-group-bandwidth"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_BANDWIDTH "priority-bandwidth"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_STRICT_BANDWIDTH "priority-strict-bandwidth"
|
|
|
|
|
#define NM_SETTING_DCB_PRIORITY_TRAFFIC_CLASS "priority-traffic-class"
|
|
|
|
|
|
2016-05-05 09:36:32 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingDcb:
|
2017-03-10 20:04:34 +01:00
|
|
|
*
|
|
|
|
|
* Data Center Bridging Settings
|
2016-05-05 09:36:32 +02:00
|
|
|
*/
|
2014-10-21 22:09:52 -04:00
|
|
|
struct _NMSettingDcb {
|
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
|
|
|
} NMSettingDcbClass;
|
|
|
|
|
|
|
|
|
|
GType nm_setting_dcb_get_type(void);
|
|
|
|
|
|
|
|
|
|
NMSetting *nm_setting_dcb_new(void);
|
|
|
|
|
|
|
|
|
|
NMSettingDcbFlags nm_setting_dcb_get_app_fcoe_flags(NMSettingDcb *setting);
|
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_dcb_get_app_fcoe_priority(NMSettingDcb *setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
const char * nm_setting_dcb_get_app_fcoe_mode(NMSettingDcb *setting);
|
|
|
|
|
|
|
|
|
|
NMSettingDcbFlags nm_setting_dcb_get_app_iscsi_flags(NMSettingDcb *setting);
|
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_dcb_get_app_iscsi_priority(NMSettingDcb *setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
NMSettingDcbFlags nm_setting_dcb_get_app_fip_flags(NMSettingDcb *setting);
|
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_dcb_get_app_fip_priority(NMSettingDcb *setting);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/* Priority Flow Control */
|
|
|
|
|
NMSettingDcbFlags nm_setting_dcb_get_priority_flow_control_flags(NMSettingDcb *setting);
|
|
|
|
|
gboolean nm_setting_dcb_get_priority_flow_control(NMSettingDcb *setting, guint user_priority);
|
|
|
|
|
void nm_setting_dcb_set_priority_flow_control(NMSettingDcb *setting,
|
|
|
|
|
guint user_priority,
|
|
|
|
|
gboolean enabled);
|
|
|
|
|
|
|
|
|
|
/* Priority Groups */
|
|
|
|
|
NMSettingDcbFlags nm_setting_dcb_get_priority_group_flags(NMSettingDcb *setting);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
guint nm_setting_dcb_get_priority_group_id(NMSettingDcb *setting, guint user_priority);
|
|
|
|
|
void
|
|
|
|
|
nm_setting_dcb_set_priority_group_id(NMSettingDcb *setting, guint user_priority, guint group_id);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
guint nm_setting_dcb_get_priority_group_bandwidth(NMSettingDcb *setting, guint group_id);
|
|
|
|
|
void nm_setting_dcb_set_priority_group_bandwidth(NMSettingDcb *setting,
|
|
|
|
|
guint group_id,
|
|
|
|
|
guint bandwidth_percent);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
guint nm_setting_dcb_get_priority_bandwidth(NMSettingDcb *setting, guint user_priority);
|
|
|
|
|
void nm_setting_dcb_set_priority_bandwidth(NMSettingDcb *setting,
|
|
|
|
|
guint user_priority,
|
|
|
|
|
guint bandwidth_percent);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
gboolean nm_setting_dcb_get_priority_strict_bandwidth(NMSettingDcb *setting, guint user_priority);
|
|
|
|
|
void nm_setting_dcb_set_priority_strict_bandwidth(NMSettingDcb *setting,
|
|
|
|
|
guint user_priority,
|
|
|
|
|
gboolean strict);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
guint nm_setting_dcb_get_priority_traffic_class(NMSettingDcb *setting, guint user_priority);
|
|
|
|
|
void nm_setting_dcb_set_priority_traffic_class(NMSettingDcb *setting,
|
|
|
|
|
guint user_priority,
|
|
|
|
|
guint traffic_class);
|
|
|
|
|
|
|
|
|
|
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_DCB_H__ */
|