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

Changes between Version 7 and Version 8 of Logging

2012-10-05T09:47:51Z (8 years ago)
Vojtech Horky

Several notes about how it works


  • Logging

    v7 v8  
    172172== Behind the scene ==
    173 TODO - how logger, logset and log_*() works
     174The logging system is composed of three parts: `logger` service, `logset` utility and the application using the logging.
     176The `logger` service is an init task and it takes care of printing the messages and also remembers the reporting levels for each log.
     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>`.
     180The application uses API from `libc` to create logs and send log messages to the logger.
     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.
     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.
     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?
     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.
     193#define log_msg(log, level, ...) \
     194   if (_log_enabled(log, level)) { \
     195       _log_msg(log, level, __VA_ARGS__); \
     196   }
     198Note that the above was partially implemented during rewriting of the logging system but was later discarded because of bugs.