Changes between Version 7 and Version 8 of Logging

Timestamp:

2012-10-05T09:47:51Z (12 years ago)

Author:

Vojtech Horky

Comment:

Several notes about how it works

Logging

@@ -171 +171 @@
 
 == Behind the scene ==
-TODO - how logger, logset and log_*() works 
+
+The logging system is composed of three parts: `logger` service, `logset` utility and the application using the logging.
+
+The `logger` service is an init task and it takes care of printing the messages and also remembers the reporting levels for each log.
+
+The `logset` utility is a front-end to the `logger` that can change the reporting levels of existing logs. The same can be done through a C API from `<io/logctl.h>`.
+
+The application uses API from `libc` to create logs and send log messages to the logger.
+
+To prevent sending the whole message even if it is not going to be printed, the `logger` may respond to the initial `LOGGER_WRITER_MESSAGE` with `ENAK` to signal that it is useless to send the buffer.
+
+
+== Assorted thoughts for improvements ==
+The `logger` can easily become a bottleneck of the whole logging system. Maybe the client themselves shall write the messages to the file and `logger` would only forward reporting level changes to the applications.
+
+However, this way it would be easier to add another target where the messages would be stored - e. g. it might be interesting to be able to send the messages over network. Maybe `logger` shall only forward the buffers?
+
+If it would turn out that even the not-printed debug messages slow down the system too much, it might be possible to limit even more the number of IPC messages and `asprintf` calls. There could be a dedicated fibril that would connect to the `logger` and would only send message reply-when-level-changed that the `logger` would answer only if there would be a change of the reported level in one of the logs. This fibril would then propagate this information into the locally stored `log_t` and `log_msg()` would be able to return much earlier. Also, if the function `log_msg()` would be replaced with a macro, there would be no need to format the message at all if the message would not be going to be printed. Below is an idea how to do such macro.
+{{{
+#!c
+#define log_msg(log, level, ...) \
+   if (_log_enabled(log, level)) { \
+       _log_msg(log, level, __VA_ARGS__); \
+   }
+}}}
+Note that the above was partially implemented during rewriting of the logging system but was later discarded because of bugs.