Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default

Nashif, Anas

I fully agree with your first paragraph but then I got completely lost how enabling logging is going to solve the issue you have presented. Frankly, the first thing I do when trying out an application is turn off all the logging, because it gets in the way, it is too verbose and it also disturbs the net shell which is enabled in many applications.

The main problem I see in many of the networking samples is the fact that we have developers designing the applications for their needs and for their own testing environment, i.e. we do have most configurations with whatever is needed to run in Qemu and in many cases with logging enabled and with kernel and networking options that worked for "someone" at "some point".

The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased, depending on usage and memory constraints. We basically want to have configuration options that enable a feature safely without having to worry about details, this might increase the binary size and memory usage, but should be possible to be customized down if needed.

Just picking a random example:




Why do I need to deal with all of that as a "random novice user". In most cases people will just copy paste those without knowing what is going on. We should either set those to safe default values or adjust them automatically based on configured features using Kconfig.

- We do need to generalize the test setting and just maintain them in one place and keep the configurations of samples generic and hw oriented as much as possible. In a test environment we then could merge the test setting and do the qemu magic without clobbering sample configurations with local test settings like


- It would help if we had all network samples behave the same, i.e. all samples should target similar use cases, of course depending on the features being demonstrated that might not be possible, but take protocols for example and anything that would require a full network setup, we could define a setup that is easily done by the novice user and build on top of that, most basic setup I could think of, and this is just an example, more options should be possible:

- DHCPv4
- IPv4

I can here connect my board with Ethernet to a local network with DHCP and be able to send and receive data immediately. Of course this is very simplified, but if we can generalize similar functionality with similar and unified configuration options, then we will make it easy.

- Ok, it is not all bad news, Jukka and the network stack developers introduced this nice netapp interface which makes it very easy to get started and does eliminate tons of code that used to be in the application and moved it to the ip stack, so this was a huge improvement already, we need to continue optimizing into this direction.

- Finally, logging. It can be really useful and I agree we need to enable some type of logging by default (which can be turned off easily). I always get lost in the configuration of logging of network applications, you would assume that CONFIG_SYS_LOG=n would turn off everything, but it does not and there are too many variants and no easy way to understand what enables/disables what. So we do need to revisit this and think how we can easily enable/disable logging and keep it on by default without impacting binary size and performance.


-----Original Message-----
From: [] On Behalf Of Paul Sokolovsky
Sent: Wednesday, September 13, 2017 4:02 PM
Subject: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default


I more the once mentioned the issue that Zephyr IP networking is very hard to configure. It almost impossible to configure a slightly-above-trivial app from scratch: something won't work with it, usually silently.

A usual response would be "enable debug logging", but here it goes in the vicious cycle, because it's hard to enable network debug logging in Zephyr. It requires setting CONFIG_NET_LOG, then if you're lucky, you discover CONFIG_NET_LOG_GLOBAL, then you also need to figure out that you need to set CONFIG_SYS_LOG_NET_LEVEL to a cryptic numeric value.

If you think that's enough, then nah, because CONFIG_NET_LOG_GLOBAL doesn't really enable logging globally. Then maybe you trace another config option, after which you will likely either get a flood of DEBUG level logging, or find out that an important condition is not logged at all.

Debugging the configuration and debug logging itself is quite 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:


2. Describe (in the docs, or otherwise) that CONFIG_NET_LOG=n is the master switch to disable all logging at once.

3. Make sure that CONFIG_NET_LOG_GLOBAL=y actually enables logging for anything network related.

4. Make sure that any important (to user) conditions actually reported with NET_WARN() or NET_ERR(), so will be visible to a user by default.

Best Regards,
Paul | Open source software for ARM SoCs Follow Linaro:!/linaroorg - _______________________________________________
Zephyr-devel mailing list

Join to automatically receive all group messages.