Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default
Hello Piotr,toggle quoted messageShow quoted text
On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <email@example.com> wrote:
I would put it differently: we should make choices for the benefit ofI disagree with enabling logging by default, it bloats the binaryOne more vote to set the default log level to 2 (warning) but not to
I preferI 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".
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 smallBut 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
That said, we could enable logging for all sample applications but notNo, 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.
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