On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <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
feedback
(https://docs.google.com/presentation/d/1L3t6V9dr2IhUlz6f4Tc_gz1-zmt00O2aspO3IfyEtBs/edit#slide=id.g1f87755cc1_0_39)
from perspective users which says "Zephyr project would get even more
credibility if there would be device manufacturers & hobbyist".

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

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.

Cheers,
Piotr

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog