Boie, Andrew P
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.
I think CONFIG_LOG_PROCESS_SLEEP_MS and 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?