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

Paul Sokolovsky

Hello Anas,

On Thu, 14 Sep 2017 13:22:11 +0000
"Nashif, Anas" <> wrote:

I fully agree with your first paragraph but then I got completely
lost how enabling logging is going to solve the issue you have
We can approach it from another side. Let me present some cases I faced
(some of them based on other users' feedback), and you'll try to guess
what's wrong in each of them. 3 cases are presented, ranging from
warm-up (with answer presented) to "hard cases nobody knows how to

1. You build an app for a new board and it crashes on startup. The app
works on another board. What's wrong? tells what was wrong for
this particular case reported by a user.

Anas' answer: (please time how much time it took to arrive at the
"correct" answer)
Paul's answer: The system should log the error condition

2. You write an app which sends data outside. It doesn't work - just
hangs in there. What's wrong? Umm, yeah. More data: another similar app
works well, so you can exclude firewall and DNS setup. Still not
enough data? You fire up Wireshark and see that Zephyr sends out ARP
requests for So, what's wrong? This is actually quite
solvable by a speculation - except when it's end of day, and you just
try to get the flaming feature tested, not doing guesswork.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working

3. If the above went ok, see what's wrong in - so far, nobody was
able to present a truly useful trail to debug it.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working properly

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
This only shows how much twisted and confusing is the net logging
situation: I complain there's too little (error) logging, and you don't
believe me it's true. Likewise, you complain about too much of
(useless) logging, and I don't believe you either (really, I don't know
of in-tree samples which have debug-level logging enabled by default.

So I'd rather believe you then, and that's exactly the nature of my
proposal: let's enable useful logging by default, and make sure that
too-much-details logging, not interesting to a casual user, is
disabled by default.

and it also disturbs the net shell which is enabled
in many applications.
That's also shows how twisted a situation we have: a proposal to enable
little error logging faces opposition that "it'll bloat binaries", and
at the same time "net shell is enabled in many applications", which is
of course much more bloated that just some of error logging. It's also
barely usable due to lack of command history support and broken paste
from host (so you need to type in long commands manually again and

The main problem I see in many of the networking samples is the fact
The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased,
- We do need to generalize the test setting and just maintain them in
- It would help if we had all network samples behave the same, i.e.
There're many issues with network stack/apps, and we can't solve them
all at once. In this thread, I present a proposal for useful error
logging in the net stack.

- 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
Right, there were bunch of improvements in the stack lately, that's why
I submit this RFC - I think we should be ready now to tackle the
"error logging" issue.

- 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.
Cool, thanks. My RFC is exactly how to make first few steps in that


Best Regards,
Paul | Open source software for ARM SoCs
Follow Linaro:!/linaroorg -

Join to automatically receive all group messages.