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

Luiz Augusto von Dentz

Hi Paul,

On Fri, Sep 15, 2017 at 10:55 AM, Paul Sokolovsky
<> wrote:
Hello Piotr,

On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <> wrote:


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.
One more vote to set the default log level to 2 (warning) but not to
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 would put it differently: we should make choices for the benefit 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.
I don't think discussion in this direction would be productive. Because
I too don't like choices made for me, and don't appreciate someone
thinking that code size if more important than error reporting, and
making me spend hours again and again debugging whole range of issues,
from trivial to complex.

Instead, we should think what would be in the interest of users, how to
let them engage with Zephyr easily, and keep them afterwards.

We should think beyond that, we should think why, 8 months after the
project being on github, it has barely over 300 stars (which is good
for a personal spare-time project and zilch for something targetting
to influence the landscape). We should think why Zephyr TSC receives a
from perspective users which says "Zephyr project would get even more
credibility if there would be device manufacturers & hobbyist".
When you use a presentation which says:

Main benefits taking zephyr in use would come from good ble and tcp/ip stacks

I understand it can be frustrating to not have proper logs when facing
issues, but things like this happen when we are trying to move as fast
as we can, perhaps too fast? Though I agree that hobbyists would
probably help fill these gaps.

Indeed, why would somebody make commercial projects based on Zephyr
with all the investment required, if nobody invests their spare fun
time into it? Then you might think if there's a correlation between
that and it being agonizing hard to configure Zephyr and debug

Zephyr documentation specifically mentions that it's targeting small
memory footprint devices.
But above that, it targets users, so any premature optimizations of
code size at the expense of user experience are, well, strange.

Few things eat up memory quite so reliably as a couple of printfs.
The network stack has eaten up memory much reliably than printfs, so
adding few won't change picture much, but may improve user
experience considerably.

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.
No, this issue being talked up for a while now, so it's worth a
solution, not half-measures. I really mean that if you take a new
Linux distro, then it ships with printk's in kernel enabled, so if
something goes wrong during the installation or afterwards, you see it
right away, not receive kind suggestions to dig into documentation
looking for god-knows-what and build your kernel differently just to
approach answering question "what may be wrong". I mean that, just
applied to Zephyr. *Afterwards* someone can debug their stuff, and
optimize code size by disabling logging.
Comparing Zephyr with Linux is not fair really, they target completely
different environments, especially when it is concerned to runtime so
we have to keep things at certain perspective. We could perhaps have
debug builds using KConfig that selects whatever makes sense to help
with initial development/prototyping phase, things like _assert
support, warnings logging, etc.

Note, this can all be achieved without a wall of text complaining
about things that doesn't work for you, from the responses here
everyone seems quite positive with the idea of having better logging
so there is no point in keep coming with more more rants about it.

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

Luiz Augusto von Dentz

Join to automatically receive all group messages.