Re: RFC[1/2] Common logging infrastructure and API


Luiz Augusto von Dentz
 

Hi Fabian,

On Tue, Mar 1, 2016 at 12:40 PM, Chereau, Fabien
<fabien.chereau(a)intel.com> wrote:
Hello,

FYI, in thunderdome we have also created a log system solving some of the problems you mention in your RFC. Here are my 2 cents following our experience:

- In our implementation we now support only a global log level (INFO, WARNING, ERROR) + a special DEBUG level which is activated at compile time for each module separately. Originally we also had a log level per module but it quickly proved to be mostly unused by the users, while adding some complexity (conflicts between global log levels and per module log level), so we removed it, also to save space.
Which is why I commented that having log level is not really
necessary, perhaps this is even misleading since it should always be
selected at build-time not runtime where perhaps the use of levels
makes sense.

- Another feature which is critical for Curie, is the support of multi-core logging. One core is the master outputting the log on the log_backend while other slaves cores send their logs to the master using an IPC mechanism. Each log message carries the information from which core it originates, + a unified timestamp.
-1, this depends on the hardware architecture besides one can write a
driver to just proxy the logs.

- Finally, another important feature we implemented is the buffering of incoming logs in a circular buffer in RAM (on both master and slave). This allow very short log time to avoid delaying the caller of the log function. The logs are finally output on the log backend in a low priority task, which reads from the circular buffer. In case there are too many incoming logs, some logs are lost instead of blocking the program execution.
Provided the message order is keep that is probably ok, but if we do
add the timestamp support then it needs to be before it enters these
buffers. Anyway we may add timestamp support for net_buf at some
point. Btw, having it as a task probably limits this to microkernel
only doesn't it?

Join devel@lists.zephyrproject.org to automatically receive all group messages.