2019-09-10 11:19:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2012-10-31 17:19:38 +01:00
|
|
|
* Copyright (C) 2006 - 2012 Red Hat, Inc.
|
2008-11-03 04:13:42 +00:00
|
|
|
* Copyright (C) 2006 - 2008 Novell, Inc.
|
2006-02-27 04:31:52 +00: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 __NETWORKMANAGER_LOGGING_H__
|
|
|
|
|
#define __NETWORKMANAGER_LOGGING_H__
|
2006-02-27 04:31:52 +00:00
|
|
|
|
2014-04-14 12:03:05 +02:00
|
|
|
#ifdef __NM_TEST_UTILS_H__
|
|
|
|
|
#error nm-test-utils.h must be included as last header
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-04-15 08:16:00 +02:00
|
|
|
#include "nm-glib-aux/nm-logging-fwd.h"
|
2018-12-28 15:31:23 +01:00
|
|
|
|
2018-06-21 09:21:57 +02:00
|
|
|
#define NM_LOG_CONFIG_BACKEND_DEBUG "debug"
|
|
|
|
|
#define NM_LOG_CONFIG_BACKEND_SYSLOG "syslog"
|
|
|
|
|
#define NM_LOG_CONFIG_BACKEND_JOURNAL "journal"
|
|
|
|
|
|
2018-03-17 16:41:32 +01:00
|
|
|
static inline NMLogDomain
|
|
|
|
|
LOGD_IP_from_af (int addr_family)
|
|
|
|
|
{
|
|
|
|
|
switch (addr_family) {
|
|
|
|
|
case AF_INET: return LOGD_IP4;
|
|
|
|
|
case AF_INET6: return LOGD_IP6;
|
|
|
|
|
}
|
|
|
|
|
g_return_val_if_reached (LOGD_NONE);
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-01 10:20:01 +00:00
|
|
|
#define nm_log_err(domain, ...) nm_log (LOGL_ERR, (domain), NULL, NULL, __VA_ARGS__)
|
|
|
|
|
#define nm_log_warn(domain, ...) nm_log (LOGL_WARN, (domain), NULL, NULL, __VA_ARGS__)
|
|
|
|
|
#define nm_log_info(domain, ...) nm_log (LOGL_INFO, (domain), NULL, NULL, __VA_ARGS__)
|
|
|
|
|
#define nm_log_dbg(domain, ...) nm_log (LOGL_DEBUG, (domain), NULL, NULL, __VA_ARGS__)
|
|
|
|
|
#define nm_log_trace(domain, ...) nm_log (LOGL_TRACE, (domain), NULL, NULL, __VA_ARGS__)
|
2010-04-06 15:46:03 -07:00
|
|
|
|
2016-07-05 18:43:49 +02:00
|
|
|
//#define _NM_LOG_FUNC G_STRFUNC
|
|
|
|
|
#define _NM_LOG_FUNC NULL
|
|
|
|
|
|
2015-04-22 11:11:44 +02:00
|
|
|
/* A wrapper for the _nm_log_impl() function that adds call site information.
|
|
|
|
|
* Contrary to nm_log(), it unconditionally calls the function without
|
|
|
|
|
* checking whether logging for the given level and domain is enabled. */
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
#define _nm_log_mt(mt_require_locking, level, domain, error, ifname, con_uuid, ...) \
|
2015-04-22 11:11:44 +02:00
|
|
|
G_STMT_START { \
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
_nm_log_impl (__FILE__, \
|
|
|
|
|
__LINE__, \
|
2016-07-05 18:43:49 +02:00
|
|
|
_NM_LOG_FUNC, \
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
(mt_require_locking), \
|
2016-07-05 18:43:49 +02:00
|
|
|
(level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(error), \
|
2017-03-01 10:20:01 +00:00
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
2016-07-05 18:43:49 +02:00
|
|
|
""__VA_ARGS__); \
|
2015-04-22 11:11:44 +02:00
|
|
|
} G_STMT_END
|
|
|
|
|
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
#define _nm_log(level, domain, error, ifname, con_uuid, ...) \
|
|
|
|
|
_nm_log_mt (!(NM_THREAD_SAFE_ON_MAIN_THREAD), level, domain, error, ifname, con_uuid, __VA_ARGS__)
|
|
|
|
|
|
2018-04-18 14:13:28 +02:00
|
|
|
/* nm_log() only evaluates its argument list after checking
|
2014-02-12 11:44:12 +01:00
|
|
|
* whether logging for the given level/domain is enabled. */
|
2017-03-01 10:20:01 +00:00
|
|
|
#define nm_log(level, domain, ifname, con_uuid, ...) \
|
2014-02-12 11:44:12 +01:00
|
|
|
G_STMT_START { \
|
|
|
|
|
if (nm_logging_enabled ((level), (domain))) { \
|
2017-03-01 10:20:01 +00:00
|
|
|
_nm_log (level, domain, 0, ifname, con_uuid, __VA_ARGS__); \
|
2014-02-12 11:44:12 +01:00
|
|
|
} \
|
|
|
|
|
} G_STMT_END
|
2010-04-06 15:23:08 -07:00
|
|
|
|
2017-03-01 10:20:01 +00:00
|
|
|
#define _nm_log_ptr(level, domain, ifname, con_uuid, self, prefix, ...) \
|
|
|
|
|
nm_log ((level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
core/logging: don't log plain pointer value from nm_log_ptr()
Logging pointer values might reveal information that can be used to defeat
ASLR. We should avoid that.
On the other hand, it's useful to tag a logging message with the pointer
value of the "source" of the message. It helps to correlate messages and
search for relevant messages in the log.
As a compromise, use NM_HASH_OBFUSCATE_PTR(), like we do at several places
already. For example, we also log
<debug> [1566550899.7901] setup NMPlatform singleton (29a6af9867f2e5d0)
This obfuscated value is a 64 bit unsigned integer with the siphash24
hash of the raw value with a randomized seed. Of course, contrary to the
pointer value, there is a tiny chance that two different pointers hash
to the same identifier. However, that seems unlikely enough to be of no
concern. Note that this pointer value is only logged to aid debugging.
It is sufficiently unlikely that this causes confusion.
One other downside of printed the obfuscated value, is that you can no
longer read the pointer from the log and use it in gdb directly. That
might be sometimes convenient, but making this impossible is kinda the
purpose of this change.
As such, nm_log_ptr() becomes a bit of a misnomer. But not too bad, it
still is a good name. For example, if we wanted we could redefine the
NM_HASH_OBFUSCATE_PTR* macros when building "--with-more-asserts".
2019-08-23 11:13:33 +02:00
|
|
|
"%s["NM_HASH_OBFUSCATE_PTR_FMT"] " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
|
2017-03-01 10:20:01 +00:00
|
|
|
(prefix) ?: "", \
|
core/logging: don't log plain pointer value from nm_log_ptr()
Logging pointer values might reveal information that can be used to defeat
ASLR. We should avoid that.
On the other hand, it's useful to tag a logging message with the pointer
value of the "source" of the message. It helps to correlate messages and
search for relevant messages in the log.
As a compromise, use NM_HASH_OBFUSCATE_PTR(), like we do at several places
already. For example, we also log
<debug> [1566550899.7901] setup NMPlatform singleton (29a6af9867f2e5d0)
This obfuscated value is a 64 bit unsigned integer with the siphash24
hash of the raw value with a randomized seed. Of course, contrary to the
pointer value, there is a tiny chance that two different pointers hash
to the same identifier. However, that seems unlikely enough to be of no
concern. Note that this pointer value is only logged to aid debugging.
It is sufficiently unlikely that this causes confusion.
One other downside of printed the obfuscated value, is that you can no
longer read the pointer from the log and use it in gdb directly. That
might be sometimes convenient, but making this impossible is kinda the
purpose of this change.
As such, nm_log_ptr() becomes a bit of a misnomer. But not too bad, it
still is a good name. For example, if we wanted we could redefine the
NM_HASH_OBFUSCATE_PTR* macros when building "--with-more-asserts".
2019-08-23 11:13:33 +02:00
|
|
|
NM_HASH_OBFUSCATE_PTR (self) \
|
|
|
|
|
_NM_UTILS_MACRO_REST(__VA_ARGS__))
|
2014-02-12 21:54:26 +01:00
|
|
|
|
2017-10-30 14:41:01 +01:00
|
|
|
static inline gboolean
|
|
|
|
|
_nm_log_ptr_is_debug (NMLogLevel level)
|
|
|
|
|
{
|
|
|
|
|
return level <= LOGL_DEBUG;
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-12 21:54:26 +01:00
|
|
|
/* log a message for an object (with providing a generic @self pointer) */
|
2017-03-01 10:20:01 +00:00
|
|
|
#define nm_log_ptr(level, domain, ifname, con_uuid, self, prefix, ...) \
|
2014-02-12 21:54:26 +01:00
|
|
|
G_STMT_START { \
|
2017-10-30 14:41:01 +01:00
|
|
|
if (_nm_log_ptr_is_debug (level)) { \
|
2017-03-01 10:20:01 +00:00
|
|
|
_nm_log_ptr ((level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
|
|
|
|
(self), \
|
|
|
|
|
(prefix), \
|
|
|
|
|
__VA_ARGS__); \
|
2014-02-12 21:54:26 +01:00
|
|
|
} else { \
|
2016-03-03 09:20:00 +01:00
|
|
|
const char *__prefix = (prefix); \
|
|
|
|
|
\
|
2017-03-01 10:20:01 +00:00
|
|
|
nm_log ((level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
|
|
|
|
"%s%s" _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
|
|
|
|
|
__prefix ?: "", \
|
|
|
|
|
__prefix ? " " : "" _NM_UTILS_MACRO_REST(__VA_ARGS__)); \
|
2014-02-12 21:54:26 +01:00
|
|
|
} \
|
|
|
|
|
} G_STMT_END
|
|
|
|
|
|
2017-03-01 10:20:01 +00:00
|
|
|
#define _nm_log_obj(level, domain, ifname, con_uuid, self, prefix, ...) \
|
|
|
|
|
_nm_log_ptr ((level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
|
|
|
|
(self), \
|
|
|
|
|
prefix, \
|
|
|
|
|
__VA_ARGS__)
|
2014-02-12 21:54:26 +01:00
|
|
|
|
|
|
|
|
/* log a message for an object (with providing a @self pointer to a GObject).
|
|
|
|
|
* Contrary to nm_log_ptr(), @self must be a GObject type (or %NULL).
|
|
|
|
|
* As of now, nm_log_obj() is identical to nm_log_ptr(), but we might change that */
|
2017-03-01 10:20:01 +00:00
|
|
|
#define nm_log_obj(level, domain, ifname, con_uuid, self, prefix, ...) \
|
|
|
|
|
nm_log_ptr ((level), \
|
|
|
|
|
(domain), \
|
|
|
|
|
(ifname), \
|
|
|
|
|
(con_uuid), \
|
|
|
|
|
(self), \
|
|
|
|
|
prefix, \
|
|
|
|
|
__VA_ARGS__)
|
2014-02-12 21:54:26 +01:00
|
|
|
|
2014-02-12 11:17:26 +01:00
|
|
|
const char *nm_logging_level_to_string (void);
|
2014-02-12 11:30:29 +01:00
|
|
|
const char *nm_logging_domains_to_string (void);
|
2016-05-19 19:05:43 +02:00
|
|
|
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2016-05-19 19:05:43 +02:00
|
|
|
extern NMLogDomain _nm_logging_enabled_state[_LOGL_N_REAL];
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
|
2016-05-19 19:05:43 +02:00
|
|
|
static inline gboolean
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
_nm_logging_enabled_lockfree (NMLogLevel level, NMLogDomain domain)
|
2016-05-19 19:05:43 +02:00
|
|
|
{
|
|
|
|
|
nm_assert (((guint) level) < G_N_ELEMENTS (_nm_logging_enabled_state));
|
2016-05-20 18:02:56 +02:00
|
|
|
return (((guint) level) < G_N_ELEMENTS (_nm_logging_enabled_state))
|
|
|
|
|
&& !!(_nm_logging_enabled_state[level] & domain);
|
2016-05-19 19:05:43 +02:00
|
|
|
}
|
2010-05-04 12:06:00 -07:00
|
|
|
|
logging: make nm-logging thread-safe
NetworkManager is single-threaded and uses a mainloop.
However, sometimes we may need multiple threads. For example, we will
need to write sysctl values asynchronously, using the glib thread-pool.
For that to work, we also need to switch the network-namespace of the
thread-pool thread. We want to use NMPNetns for that. Hence it's better
to have NMPNetns thread-safe, instead of coming up with a duplicate
implementation. But NMPNetns may want to log, so we also need nm-logging
thread-safe.
In general, code under "shared/nm-utils" and nm-logging should be usable
from multiple threads. It's simpler to make this code thread-safe than
re-implementing it. Also, it's a bad limitation to be unable to log
from other threads. If there is an error, the best we can often do is to
log about it.
Make nm-logging thread-safe. Actually, we only need to be able to log
from multiple threads. We don't need to setup or configure logging from
multiple threads. This restriction allows us to access logging from the
main-thread without any thread-synchronization (because all changes in
the logging setup are also done from the main-thread).
So, while logging from other threads requires a mutex, logging from the
main-thread is lock-free.
2019-01-16 16:40:45 +01:00
|
|
|
gboolean _nm_logging_enabled_locking (NMLogLevel level, NMLogDomain domain);
|
|
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
|
nm_logging_enabled_mt (gboolean mt_require_locking, NMLogLevel level, NMLogDomain domain)
|
|
|
|
|
{
|
|
|
|
|
if (mt_require_locking)
|
|
|
|
|
return _nm_logging_enabled_locking (level, domain);
|
|
|
|
|
|
|
|
|
|
NM_ASSERT_ON_MAIN_THREAD ();
|
|
|
|
|
return _nm_logging_enabled_lockfree (level, domain);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define nm_logging_enabled(level, domain) \
|
|
|
|
|
nm_logging_enabled_mt (!(NM_THREAD_SAFE_ON_MAIN_THREAD), level, domain)
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2016-05-23 10:56:27 +02:00
|
|
|
NMLogLevel nm_logging_get_level (NMLogDomain domain);
|
|
|
|
|
|
2013-03-11 12:23:57 -04:00
|
|
|
const char *nm_logging_all_levels_to_string (void);
|
|
|
|
|
const char *nm_logging_all_domains_to_string (void);
|
|
|
|
|
|
2013-11-26 11:33:42 -05:00
|
|
|
gboolean nm_logging_setup (const char *level,
|
|
|
|
|
const char *domains,
|
|
|
|
|
char **bad_domains,
|
|
|
|
|
GError **error);
|
2016-10-05 15:25:08 +02:00
|
|
|
|
2019-01-16 16:16:49 +01:00
|
|
|
void nm_logging_init_pre (const char *syslog_identifier,
|
|
|
|
|
char *prefix_take);
|
|
|
|
|
|
|
|
|
|
void nm_logging_init (const char *logging_backend, gboolean debug);
|
2016-10-05 15:25:08 +02:00
|
|
|
|
2016-05-23 12:02:31 +02:00
|
|
|
gboolean nm_logging_syslog_enabled (void);
|
2006-02-27 04:31:52 +00:00
|
|
|
|
2015-08-20 00:07:14 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2016-10-14 15:32:56 +02:00
|
|
|
#define __NMLOG_DEFAULT(level, domain, prefix, ...) \
|
|
|
|
|
G_STMT_START { \
|
2017-03-01 10:20:01 +00:00
|
|
|
nm_log ((level), (domain), NULL, NULL, \
|
2016-10-14 15:32:56 +02:00
|
|
|
"%s: " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
|
|
|
|
|
(prefix) \
|
|
|
|
|
_NM_UTILS_MACRO_REST(__VA_ARGS__)); \
|
|
|
|
|
} G_STMT_END
|
|
|
|
|
|
|
|
|
|
#define __NMLOG_DEFAULT_WITH_ADDR(level, domain, prefix, ...) \
|
|
|
|
|
G_STMT_START { \
|
2017-03-01 10:20:01 +00:00
|
|
|
nm_log ((level), (domain), NULL, NULL, \
|
2019-06-25 12:49:14 +02:00
|
|
|
"%s["NM_HASH_OBFUSCATE_PTR_FMT"]: " _NM_UTILS_MACRO_FIRST(__VA_ARGS__), \
|
2016-10-14 15:32:56 +02:00
|
|
|
(prefix), \
|
2019-06-25 12:49:14 +02:00
|
|
|
NM_HASH_OBFUSCATE_PTR (self) \
|
2016-10-14 15:32:56 +02:00
|
|
|
_NM_UTILS_MACRO_REST(__VA_ARGS__)); \
|
|
|
|
|
} G_STMT_END
|
|
|
|
|
|
2019-01-15 16:41:57 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
extern void _nm_logging_clear_platform_logging_cache (void);
|
|
|
|
|
|
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 /* __NETWORKMANAGER_LOGGING_H__ */
|
