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

Nashif, Anas

Should I assume you started replying before you read my final comment about logging? :-)


-----Original Message-----
From: Paul Sokolovsky []
Sent: Thursday, September 14, 2017 12:43 PM
To: Nashif, Anas <>
Subject: Re: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default

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 presented.
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 solve".

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
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 again).

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 direction.


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

Join to automatically receive all group messages.