Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 7 and Version 8 of Logging


Ignore:
Timestamp:
2012-10-05T09:47:51Z (7 years ago)
Author:
Vojtech Horky
Comment:

Several notes about how it works

Legend:

Unmodified
Added
Removed
Modified
  • Logging

    v7 v8  
    171171
    172172== Behind the scene ==
    173 TODO - how logger, logset and log_*() works
     173
     174The logging system is composed of three parts: `logger` service, `logset` utility and the application using the logging.
     175
     176The `logger` service is an init task and it takes care of printing the messages and also remembers the reporting levels for each log.
     177
     178The `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>`.
     179
     180The application uses API from `libc` to create logs and send log messages to the logger.
     181
     182To 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.
     183
     184
     185== Assorted thoughts for improvements ==
     186The `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.
     187
     188However, 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?
     189
     190If 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.
     191{{{
     192#!c
     193#define log_msg(log, level, ...) \
     194   if (_log_enabled(log, level)) { \
     195       _log_msg(log, level, __VA_ARGS__); \
     196   }
     197}}}
     198Note that the above was partially implemented during rewriting of the logging system but was later discarded because of bugs.