mambrus / liblog Goto Github PK

Logging is also a way of printf debugging. For RT sensitive issues it may very well be the only way to understand an issue, i.e. when time is a factor of the problem itself.

For debugging purposes by enabling LOG_LEVEL=DEBUG, logs can clobber the view (and also slow down execution which in turn may cause ghost issues).

I.e. prevent that too much is logged (by log-probes from every corner of your code), by enabling only what is needed. IOW a finer granularity of control than LOG_LEVEL alone.

LOGX can be used much like linux kernel ftrace probes, by turning specific areas on and off. Thereby leaving the probes in code, but activate them only on demand using filtering.

ftrace does this using chains of rules. Exactly how liblog will leverage on the concept isn't determined as it's needed to consider more use-cases. From deeply embedded with no kernel support, to high-end UN*X based systems with abilities to use collaborating services.

Additional consideration to take into account is also to keep the configuration as low as possible to not prevent incorporation in (especially) resource constrained projects.

If liblog is used in interrupt context or by some kernels threads => libc isn't neither thread safe (newlib implementation i.e. the most common libc for MCU:s) nor re-entrant. Latter is true not only MCU use-cases.

printf with friends are also known to be unnecessarily big. For most logging purposes, floating-point handling and ditto formatting is quite un-necessary.

This may not be a liblog issue but a system issue (link which library). There may however be a need to distinguish one API from another in base both need to be used.

Labelled "investigate" for the causes mentioned above.

In (especially) embedded projects, logging to an UART directly may case RT-issues, i.e. creating new problems. This is solved by logging to RAM instead as an intermediate step, there-by decoupling the probing-phase from the print-out/inspection-phase.

(Something needs to pull the logs of-course, but that is not the primary concern in this issue as it may probably be done differently from case-to-case.)

Considerations:

• No complex configuration should be needed
• Can not rely on malloc (i.e. allocated buffert-pointers). In the deeply embedded case with low RAM boundary protection, and especially considering that logs themselves become imperative for analysing fault's, logs must not be damaged.