summaryrefslogtreecommitdiff
path: root/src/nm-dcb.h
Commit message (Collapse)AuthorAgeFilesLines
* all: cleanup includes in header filesThomas Haller2016-08-171-1/+0
| | | | | | | | | | | | - don't include "nm-default.h" in header files. Every source file must include as first header "nm-default.h", thus our headers get the default include already implicitly. - we don't support compiling NetworkManager itself with a C++ compiler. Remove G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support users of libnm to use C++, thus they stay in public headers. (cherry picked from commit f19aff89095ca192b8b2e37534b7a899aecd82f9)
* all: make use of new header file "nm-default.h"Thomas Haller2015-08-051-1/+1
|
* all: rename nm-glib-compat.h to nm-glib.h, use everywhereDan Winship2015-07-241-1/+1
| | | | | | | | | | | | | | | | Rather than randomly including one or more of <glib.h>, <glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include "nm-glib-compat.h" most of the time), rename nm-glib-compat.h to nm-glib.h, include <gio/gio.h> from there, and then change all .c files in NM to include "nm-glib.h" rather than including the glib headers directly. (Public headers files still have to include the real glib headers, since nm-glib.h isn't installed...) Also, remove glib includes from header files that are already including a base object header file (which must itself already include the glib headers).
* core: drop all remaining core-internal error domainsDan Winship2014-10-221-24/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | A number of classes in core had their own error domains that aren't really necessary. In the case of NMDcbError, NMDhcpManagerError, NMDnsManagerError, NMDnsmasqManagerError, NMPppManagerError, and NMSessionMonitorError, most of the codes they defined weren't even being used, and at any rate, the errors were always returned into contexts where they would just have their message extracted and then get thrown away without anyone ever looking at the domain or code. So all uses of those domains can just be replaced with NM_MANAGER_ERROR_FAILED without any loss of information. NMAuthManagerError only had 1 error code, and it just indicated "something went wrong", so it can be replaced with NM_MANAGER_ERROR_FAILED without loss of information. (nm-auth-manager.c has also been fixed to return NM_MANAGER_ERROR_FAILED when the CheckAuthorization D-Bus call fails, rather than returning whatever error domain/code the D-Bus call returned.) NMVpnManagerError used 2 of its 4 error codes, and they could actually end up getting returned across D-Bus in some cases. But there are NMManagerError codes that are semantically similar enough to make the NMVpnManagerError ones unnecessary.
* all: fix up multiple-include-guard definesDan Winship2014-08-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* dcb: separate DCB enable/disable and wait for carrier changes (rh #799241) ↵Dan Williams2014-04-021-0/+7
| | | | | | | | | | | | | | | | | | | | | (rh #1081991) Non-git-master versions of lldpad refuse to touch a device that doesn't have a carrier. And when enabling/disabling DCB, the kernel driver will reconfigure itself and may turn carrier off for a few seconds. So we must ensure that before enabling/disabling DCB, the carrier is already on. Next we must ensure that *after* enabling/disabling DCB, the carrier is back on before doing further DCB setup. There's a race condition between enabling/disabling DCB and receiving the carrier event in NetworkManager that has to be handled carefully. Because the carrier may not yet be down after the dcbtool call to enable/disable DCB returns, we need to wait for a couple seconds for the carrier to go down, and then again for it to come back up. Otherwise we might see the still-on carrier, proceed with DCB setup, and the carrier finally goes down halfway through the setup, which will fail the operations with "DCB not enabled, link down, or DCB not supported" errors from lldpad.
* core: add dcbtool manipulation logicDan Williams2013-10-311-0/+93