fdo-mirrors/wireplumber
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/wireplumber.git synced 2025-12-20 19:20:04 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
wireplumber/lib/wp/log.h

160 lines
5.3 KiB
C
Raw Normal View History

lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
/* WirePlumber
*
* Copyright © 2020 Collabora Ltd.
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
*
* SPDX-License-Identifier: MIT
*/
wp: rename debug.{h,c} to log.{h,c} Also rename the intermediate lua api table WpDebug -> WpLog Keeps things more consistent with the function names (wp_log*), with the lua api (Log.*) and with pipewire using log.{h,c} as well. After all, these functions are for logging...
2021-05-06 15:45:13 +03:00
#ifndef __WIREPLUMBER_LOG_H__
#define __WIREPLUMBER_LOG_H__
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#include <glib-object.h>
#include "defs.h"
G_BEGIN_DECLS
#define WP_LOG_LEVEL_TRACE (1 << G_LOG_LEVEL_USER_SHIFT)
#define WP_OBJECT_FORMAT "<%s:%p>"
debug: handle null objects in WP_OBJECT_ARGS
2020-05-05 16:26:15 +03:00
#define WP_OBJECT_ARGS(object) \
(object ? G_OBJECT_TYPE_NAME(object) : "invalid"), object
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
WP_PRIVATE_API
void wp_log_init (gint flags);
wp: make wp_log_set_global_level public API Applications may want to change WP log level at runtime. Also change it to return error stataus instead of printing warnings on error.
2023-12-07 18:48:07 +02:00
WP_API
gboolean wp_log_set_global_level (const gchar *log_level);
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
typedef struct _WpLogTopic WpLogTopic;
struct _WpLogTopic {
const char *topic_name;
/*< private >*/
/*
* lower 16 bits: GLogLevelFlags
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
* bit 29: has_custom_level
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
* bit 30: a g_bit_lock
* bit 31: 1 - initialized, 0 - not initialized
*/
gint flags;
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
gint *global_flags;
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
WP_PADDING(2)
};
#define WP_LOG_TOPIC_EXTERN(var) \
extern WpLogTopic * var;
#define WP_LOG_TOPIC(var, t) \
WpLogTopic var##_struct = { .topic_name = t, .flags = 0 }; \
WpLogTopic * var = &(var##_struct);
#define WP_LOG_TOPIC_STATIC(var, t) \
static WpLogTopic var##_struct = { .topic_name = t, .flags = 0 }; \
static G_GNUC_UNUSED WpLogTopic * var = &(var##_struct);
#define WP_DEFINE_LOCAL_LOG_TOPIC(t) \
WP_LOG_TOPIC_STATIC(WP_LOCAL_LOG_TOPIC, t)
/* make glib log functions also use the local log topic */
#ifdef G_LOG_DOMAIN
# undef G_LOG_DOMAIN
#endif
#define G_LOG_DOMAIN (WP_LOCAL_LOG_TOPIC->topic_name)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
WP_API
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
void wp_log_topic_init (WpLogTopic *topic);
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
static inline gboolean
wp_log_topic_is_initialized (WpLogTopic *topic)
{
return (topic->flags & (1u << 31)) != 0;
}
static inline gboolean
wp_log_topic_has_custom_level (WpLogTopic *topic)
{
return (topic->flags & (1u << 29)) != 0;
}
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
static inline gboolean
wp_log_topic_is_enabled (WpLogTopic *topic, GLogLevelFlags log_level)
{
/* first time initialization */
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
if (G_UNLIKELY (!wp_log_topic_is_initialized (topic)))
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log_topic_init (topic);
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
if (wp_log_topic_has_custom_level (topic))
log: fix log level mask to be able to test the trace level Trace is 1<<8 and the mask was 0xFF, allowing only bits 0-7 to be tested
2023-05-25 17:59:56 +03:00
return (topic->flags & (log_level & 0xFFFF)) != 0;
log: improve the initialization process * initialize all log-related features in a new wp_log_init() function * remove the ability to change the log patterns later, as the log topics are not referenced by the log system and there is no way to re-initialize them with different levels (we can still implement this in the future, if necessary, though) * introduce the notion of a "global log level", referenced by all topics, and make the topics know if they have a custom level or not, like in pipewire; this is necessary to be able to set the level in the config file, which is read later by pw_context / WpCore.
2023-05-17 23:54:49 +03:00
else
log: fix log level mask to be able to test the trace level Trace is 1<<8 and the mask was 0xFF, allowing only bits 0-7 to be tested
2023-05-25 17:59:56 +03:00
return (*topic->global_flags & (log_level & 0xFFFF)) != 0;
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
}
#define wp_local_log_topic_is_enabled(log_level) \
(wp_log_topic_is_enabled (WP_LOCAL_LOG_TOPIC, log_level))
log: factor out the log level configuration into wp_log_level_set() Initialize the log level with WIREPLUMBER_DEBUG in wp_init()
2021-04-21 13:03:47 +03:00
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
WP_API
GLogWriterOutput wp_log_writer_default (GLogLevelFlags log_level,
const GLogField *fields, gsize n_fields, gpointer user_data);
WP_API
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
void wp_log_checked (const gchar *log_topic, GLogLevelFlags log_level,
const gchar *file, const gchar *line, const gchar *func,
GType object_type, gconstpointer object,
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
const gchar *message_format, ...) G_GNUC_PRINTF (8, 9);
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
#define wp_log(topic, level, type, object, ...) \
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
({ \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
if (G_UNLIKELY (wp_log_topic_is_enabled (topic, level))) \
wp_log_checked (topic->topic_name, level, __FILE__, G_STRINGIFY (__LINE__), \
G_STRFUNC, type, object, __VA_ARGS__); \
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
})
debug: add wp_critical* macros
2020-05-01 12:00:28 +03:00
#define wp_critical(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_CRITICAL, 0, NULL, __VA_ARGS__)
debug: update all library code to use the new debug system + enable the new log writer on the executables + enable structured logging in the tests
2020-04-14 18:31:17 +03:00
#define wp_warning(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_WARNING, 0, NULL, __VA_ARGS__)
log: rename "message" level to "notice" and print criticals with "E" Syslog calls this level "notice" and I prefer it because we use it to display significant messages that are not warnings, but they are not really "standard", as GLib wants them to be. There is nothing "standard" about log messages in general. Also, make these notice messages be enabled at debug level 2, together with warnings. The default log.level is 2 and it is a good idea to show notices by default too. Finally, show them in the log with "N" and also change criticals to be shown with "E", meaning "error"... Then promote G_LOG_LEVEL_ERROR messages to be shown with "F", meaning "fatal", because in fact these messages are always fatal and always call abort(). Still, keep the term "critical" in the functions to make sure that whoever uses them is aware that this level is only for critical conditions and not suitable to display any kind of error.
2023-05-18 16:19:49 +03:00
#define wp_notice(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_MESSAGE, 0, NULL, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_info(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_INFO, 0, NULL, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_debug(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_DEBUG, 0, NULL, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_trace(...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, WP_LOG_LEVEL_TRACE, 0, NULL, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
debug: add wp_critical* macros
2020-05-01 12:00:28 +03:00
#define wp_critical_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_CRITICAL, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
debug: update all library code to use the new debug system + enable the new log writer on the executables + enable structured logging in the tests
2020-04-14 18:31:17 +03:00
#define wp_warning_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_WARNING, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
log: rename "message" level to "notice" and print criticals with "E" Syslog calls this level "notice" and I prefer it because we use it to display significant messages that are not warnings, but they are not really "standard", as GLib wants them to be. There is nothing "standard" about log messages in general. Also, make these notice messages be enabled at debug level 2, together with warnings. The default log.level is 2 and it is a good idea to show notices by default too. Finally, show them in the log with "N" and also change criticals to be shown with "E", meaning "error"... Then promote G_LOG_LEVEL_ERROR messages to be shown with "F", meaning "fatal", because in fact these messages are always fatal and always call abort(). Still, keep the term "critical" in the functions to make sure that whoever uses them is aware that this level is only for critical conditions and not suitable to display any kind of error.
2023-05-18 16:19:49 +03:00
#define wp_notice_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_MESSAGE, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_info_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_INFO, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_debug_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_DEBUG, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_trace_object(object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, WP_LOG_LEVEL_TRACE, (object) ? G_TYPE_FROM_INSTANCE (object) : G_TYPE_NONE, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
debug: add wp_critical* macros
2020-05-01 12:00:28 +03:00
#define wp_critical_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_CRITICAL, type, object, __VA_ARGS__)
debug: update all library code to use the new debug system + enable the new log writer on the executables + enable structured logging in the tests
2020-04-14 18:31:17 +03:00
#define wp_warning_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_WARNING, type, object, __VA_ARGS__)
log: rename "message" level to "notice" and print criticals with "E" Syslog calls this level "notice" and I prefer it because we use it to display significant messages that are not warnings, but they are not really "standard", as GLib wants them to be. There is nothing "standard" about log messages in general. Also, make these notice messages be enabled at debug level 2, together with warnings. The default log.level is 2 and it is a good idea to show notices by default too. Finally, show them in the log with "N" and also change criticals to be shown with "E", meaning "error"... Then promote G_LOG_LEVEL_ERROR messages to be shown with "F", meaning "fatal", because in fact these messages are always fatal and always call abort(). Still, keep the term "critical" in the functions to make sure that whoever uses them is aware that this level is only for critical conditions and not suitable to display any kind of error.
2023-05-18 16:19:49 +03:00
#define wp_notice_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_MESSAGE, type, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_info_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_INFO, type, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_debug_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, G_LOG_LEVEL_DEBUG, type, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
#define wp_trace_boxed(type, object, ...) \
log: implement a log topics system, like pipewire The intention is to make checks for enabled log topics faster. Every topic has its own structure that is statically defined in the file where the logs are printed from. The structure is initialized transparently when it is first used and it contains all the log level flags for the levels that this topic should print messages. It is then checked on the wp_log() macro before printing the message. Topics from SPA/PipeWire are also handled natively, so messages are printed directly without checking if the topic is enabled, since the PipeWire and SPA macros do the checking themselves. Messages coming from GLib are checked inside the handler. An internal WpLogFields object is used to manage the state of each log message, populating all the fields appropriately from the place they are coming from (wp_log, spa_log, glib log), formatting the message and then printing it. For printing to the journald, we still use the glib message handler, converting all the needed fields to GLogField on demand. That message handler does not do any checks for the topic or the level, so we can just call it to send the message.
2023-05-16 11:51:29 +03:00
wp_log (WP_LOCAL_LOG_TOPIC, WP_LOG_LEVEL_TRACE, type, object, __VA_ARGS__)
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
lib: implement a wp_init() function
2020-05-11 15:45:09 +03:00
struct spa_log;
debug: add support for redirecting pipewire's log to the glib one
2020-04-14 14:59:55 +03:00
WP_API
lib: implement a wp_init() function
2020-05-11 15:45:09 +03:00
struct spa_log * wp_spa_log_get_instance (void);
debug: add support for redirecting pipewire's log to the glib one
2020-04-14 14:59:55 +03:00
lib: add a debug logging system This extends GLib's logging system, so it is compatible with g_debug() and friends, but it uses a better logging format and supports filtering debug domains with wildcards, like in gst.
2020-04-14 12:16:41 +03:00
G_END_DECLS
#endif
Reference in a new issue Copy permalink