Re: logging subsys questions / concerns

Carles Cufi

Hi Andrew,

Thanks for all the feedback.
As agreed on Slack I am copying Krzysztof and Jakub here so that they see your comments and then, if applicable, we can create one or more issues alongside the ones that Paul has already opened.



-----Original Message-----
From: <> On
Behalf Of Boie, Andrew P
Sent: 28 November 2018 21:01
To: zephyr-devel <>
Subject: [Zephyr-devel] logging subsys questions / concerns

I've been looking at the logging subsystem code and I wanted to bring up
some topics.

1) The default priority of the logging thread is -2. This is a very high
non preemptive priority. I don't understand why the logging background
thread doesn't run at the lowest preemptible priority on the system,
like the idle thread. If people are running out of buffer space then
they need to make their buffers bigger or switch to synchronous logging.

2) The panic mode handling is not correct. It gets called from
_NanoFatalErrorHandler, which flushes the log and then sets the
panic_mode global *permanently* to true. This is not a good policy.
NanoFatalErrorHandler getting called does not necessarily mean that the
system has completely crashed, it's quite possible that the damage is
limited to one thread dying, with the rest of the threads (and the
overall system) still running just fine. I think we need to move the
invocation of LOG_PANIC until *much* later, when we decide we need to
hang the system instead of just aborting the faulting thread.

3) It does not appear that there is any support for invoking LOG()
macros from user mode, which severely limits its usability. Until there
is an answer to this, conversations about default mapping printk() to
the log subsystem really scare me. Is LOG intended to be used by end
user applications or just internally to the kernel?

4) The synchronization between threads invoking log points, and the
background logging thread, do not make sense to me, and seem to be a way
of dealing with making the log thread default to a very high non-
preemptible priority, which I already complained about.

CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD should be completely removed.
Introduce a k_sem with initial count 0 and max count UINT_MAX. Log
points have the caller give the semaphore every time something is added
to the log buffer, and have the background thread simply do a blocking
k_sem_take(). So much simpler, and we rely on the scheduler to do its
job instead of this weird setup where the log thread is high priority
but sleeps for hard-coded intervals.

5) What does it mean if CONFIG_LOG_INPLACE_PROCESS=n, but
CONFIG_LOG_PROCESS_THREAD=n? Can we simplify our Kconfigs?

Join to automatically receive all group messages.