Logging library

[rmu75]

In #4627 it came up that we do want a more modern logging facilty. This discussion should be the place to gather requirements and possible candidate libraries. This concerns non-realtime user-space stuff like setup/tear down code, GUI and language interfaces, message pumping/processing, task and similar stuff.

I (@rmu75) would want interface with fmtlib style type safe formatting, some shortcuts to specify severity level and possibility of central configuration of log targets (like file, stderr, GUI, whatever).

No-effort googling yields spdlog https://github.com/gabime/spdlog as candidate (also packaged in debian).

[alex-pres]

spdlog is cool, I used it in other projects and it just works.

[hdiethelm]

The main issue I see with logging in LinuxCNC are the mostly unconnected processes and the different languages. In an ideal world, all parts would log to the same facility in the same format. From there, it can be shown in GUI's, printed to the console, translated to the users language, forwarded to your CNC fleet logging back-end or whatever is needed.

This needs some custom code. Or does spdlog support such a thing? I'm pretty sure spdlog won't work in kernel. Does it work for python? C? Bash? tcl/tk?

Right now, logs are random where they appear. Sometimes in the terminal linuxcnc was started, sometimes in the terminal a command was executed and especially for halcmd, the important logs normally appear in the terminal linuxcnc was started, not in the one the command was executed.

Just to see how spdlog would look, I created a prototype: https://github.com/hdiethelm/linuxcnc-fork/tree/spdlog_prototype but this is not a real solution, it just logs from different processes to stderr. Still, I like the spdlog format, and I think it can be used to show the messages in the terminal.

Right now, components log trough rtapi_app or rtai/rt_printk. As soon as motion is loaded, error messages go also to the gui. That has the side effect that all errors before loading motion are not shown in the gui. And had the issue that errors after initializing motion where not shown at all if motion crashed. Fixed in #4116

This could be solved by creating a real time logging facility inside hallib.

From my side, some requirements for good logging:

• It needs to be robust. Loosing the last logs before a hard crash is a nightmare to debug.
• Same general look and feel, independent from where logging is done. Ideally in all used programming languages.
• Global configuration for active log level
• Log level can be set by module. TBD how to set the module boundary's. This could be:
  • Per HAL component
  • You specify the module by a static LOG_MODULE("module1") in each file.
  • ... Ideas are welcome
• Timestamp
• File/Line information (So you don't have to grep the source and guessing which of the 10 hits it was...)

I know, this is a lot to ask for. But just replacing one glorified printf by another one does not help that much at the end.

[BsAtHome]

Just to name a few things:

• You need a runtime system (may be limited to startup config) to enable/disable messages.
• You want a channelized system that is fine-grained enough to select the parts of interest and disable the rest (see Wine as an example).
• You want an API accessible from both core code and user space processes so that there is one (1) interface and logging system used by all which output can be controlled in any way you wish to configure.
• We need to review the entire code base to do structured logging using a recognizable format such that the same type of message have the same structure. In this process, we need to look at error handling and clean that up too.
• We need to do translations consistently for all messages.
• We need to revamp the translation structure to support more fine-grained .pot files instead of one-big-pile-of-text.

[rmu75]

The logging facility should be made available to python and tcl/tk via their respective linuxcnc interfaces.

[BsAtHome]

The logging facility should be made available to python and tcl/tk via their respective linuxcnc interfaces.

We should remove all Tcl/tk from the core code in the next version. Its only use could be in python, but independent Tcl/tk code should be ported to python.