bacnet-stack
Improve logging mechanism
Currently I feel that logging is little mess. We print sometimes to stderr and sometimes to stdout. Also problem is that is hard to define custom mechanism without changing source. Also examples use various mechanisms to do logging.
I propose that we will have logging macros like example blog_error, blog_info, blog_debug. Then we will also implement way to set custom callback so anyone can easily change where and how to log things. I made demo about this thing to godbolt 1.
- Now changing log level affects so that we will compile time optimize away messages we do not want. This is nice when someone wants to build smaller program.
- Now logging support also coloring.
- Default print function will print fatal and err to stderr and everything else to stdout.
- Does use variadic macros. I plan to do it so cmake will check if compiler support those if not it will use DEBUG_LEVEL 0 and print warning that logging is disabled. Without variadic macros this kind of thing is really hard so I would vote that we do not even try.
- Logging level can be changed at runtime. Note that if level was compile time example WARN you cannot get TRACE message even if you set level to it as those are now compile time optimized away. At least we do not need this functionality but was wondering that some others might want it.
- I choose to make callback very minimal so we do not even format str before. User needs to format those themselves.
- Note that godbolt prints stderr first and then stdout. It is just godbolt thing.
Is anyone against this idea? Details we can work later.
I like the idea of adding a 'logging' subsystem of some kind.
Some thoughts:
-
I worked with application logging in Contiki-OS and with Zephyr OS, and we could adopt something similar to Contiki-OS. I already adopted mstimer.c from Contiki-OS for internal non-blocking timers.
-
The additional requirements for the command line applications are printing results to stdout and sending warnings and errors to stderr to give helpful clues to users of the command line applications or stderr can be piped to dev/null. The stdout typcially follows a specified format, such as that from ASHRAE 135.1 EPICS TPI format, so a 'logger' would need to accomodate both, or be able to support multiple views. There have been requests to use JSON format for the output from the command line applications[#211].
-
Most (all?) of the basic service handlers that print are shared by deeply embedded code that is used in microcontrollers without any printing interface.
@nazaryev-cool, I'm very interested in your logging branch Is it something you're planning to PR into master? If so, what remains to be completed?
