Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default
|
Nashif, Anas
Re (1): in this spirit, I would also enable CONFIG_ASSERT by default...
toggle quoted message
Show quoted text
Re (4): SYS_LOG itself is not the issue, it is the layers added on top of it to enable logging in subsystems such as the IP stack which is confusing to say the least and has been discussed in this thread. We will have situations where we do want to using printk and family to print out kernel level exceptions and oopses, even if the logging was disabled for whatever reason, although the SYS_LOG could be optimized to handle such cases as well, we do have logger hooks that can for example write to a file system instead of the console in production systems, so depending on printk for all messages (and assuming console is always connected) is already not ideal. This goes beyond the original thread topic and is probably worth a bug/enhancement request to be tracked. Anas -----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Boie, Andrew P Sent: Friday, September 15, 2017 1:52 PM To: Paul Sokolovsky <paul.sokolovsky@...>; Luiz Augusto von Dentz <luiz.dentz@...> Cc: zephyr-devel@... Subject: Re: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default My views on this topic: 1) Right now we have very inconsistent error/debug logging. In lots of places in the kernel, when a bad situation is encountered the problem is simply reported with a printk(). In other places we are using SYS_LOG_*. The default experience for the user is that all the SYS_LOG messages are suppressed, but the printks are emitted. This is not an ideal default configuration, in fact words like "horrible" and "baffling" come to mind when considering it. 2) I still think that SYS_LOG should be turned on by default for error and warning situations, just like printk() is on by default. 3) If people are concerned about code size, there should be some kind of global flag which suppresses all debug output, including printk(). In the future, for very RAM constrained devices we could implement a backend to SYS_LOG which uses tricks like storing format strings completely outside the binary, in an external file used to decode raw log data, stuff like that. 4) The way SYS_LOG_* is configured in Kconfig is currently a confusing disaster and I look forward to seeing what Paul comes up with to clean it up. I think the difficulty in using this mechanism is at least partly why large parts of the kernel do not use it and just do printks instead. 5) We may consider making printk() a thin wrapper for a particular level of SYS_LOG(). Andrew _______________________________________________ Zephyr-devel mailing list Zephyr-devel@... https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel |
|
|