On Tue, 2016-03-01 at 16:15 +0000, Chereau, Fabien wrote:
-----Original Message-----Indeed, my point was just to make sure at API level that such custom
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, March 1, 2016 16:55
Subject: [devel] Re: Re: Re: Re: Re: RFC[1/2] Common logging
logging. One core is the master outputting the log on the
- Another feature which is critical for Curie, is the support
other slaves cores send their logs to the master using an IPC
Each log message carries the information from which core it
originates, + a
-1, this depends on the hardware architecture besides one canI don't see anything we could do about that in this logging API.
driver to just proxy the logs.
If there is something to be done, let's see it in another patch.
implementations are pluggable.
I understand, for this first effort the goal is to unify calls under a
single API that can be later provided by different implementations. I
don't foresee conflicts between initial proposal and Fabien's insights.
incoming logs in a circular buffer in RAM (on both master and
- Finally, another important feature we implemented is the
allow very short log time to avoid delaying the caller of the log
logs are finally output on the log backend in a low priority task,
from the circular buffer. In case there are too many incoming logs,
are lost instead of blocking the program execution.
Provided the message order is keep that is probably ok, but if weNanokernel could get it, it would run in low prio fiber and that's
add the timestamp support then it needs to be before it enters
buffers. Anyway we may add timestamp support for net_buf at some
point. Btw, having it as a task probably limits this to
only doesn't it?
Imo, let's not bother fixing this right now in this API. This goes
(as I said, instead of having printk/printf we could have a new
sys_log() functions that could act
as a log buffering proxy, fully optional etc...)