Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default
Piotr Mienkowski
Hi,
On 14.09.2017 08:33, Jukka Rissanen wrote:
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good idea,
maybe even level 3 if we clean up _INF messages, seeing assigned MAC
address, IP number in the log wouldn't be all that bad) but we should
avoid making choices on behalf of the users. I prefer to enable options
that I need when I need them rather than disable all those I don't only
because someone believed they are good for me. Zephyr documentation
specifically mentions that it's targeting small memory footprint
devices. Few things eat up memory quite so reliably as a couple of printfs.
That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.
Cheers,
Piotr
On 14.09.2017 08:33, Jukka Rissanen wrote:
One more vote to set the default log level to 2 (warning) but not toDebugging the configuration and debug logging itself is quiteWe could set the log level to 2 (warn) as you suggest, there was not
painful,
after a year on Zephyr, I still didn't master it, what to say about
newcomers?
So, I'd like to propose to make following changes:
1. Enable CONFIG_NET_LOG=y, CONFIG_NET_LOG_GLOBAL=y,
CONFIG_SYS_LOG_NET_LEVEL=2 (WARN) by default.
many warns in the net stack anyway.
I disagree with enabling logging by default, it bloats the binary and
also increases ram / stack usage. Normally you do not need to have
debugging enabled anyway, and if you need it, then it is easy to set
CONFIG_NET_LOG=y, enable individual component logging or global
logging, and then increase the log level.
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good idea,
maybe even level 3 if we clean up _INF messages, seeing assigned MAC
address, IP number in the log wouldn't be all that bad) but we should
avoid making choices on behalf of the users. I prefer to enable options
that I need when I need them rather than disable all those I don't only
because someone believed they are good for me. Zephyr documentation
specifically mentions that it's targeting small memory footprint
devices. Few things eat up memory quite so reliably as a couple of printfs.
That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.
Cheers,
Piotr