I don't see anything we could do about that in this logging API.- 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
If there is something to be done, let's see it in another patch.
Nanokernel could get it, it would run in low prio fiber and that's it.- 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
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...)