logging: Use vprintk for stirng formatting by default #14036
Conversation
|
This change reduces log thread stack usage by 260 bytes. So we shall see less errors due to stack overflows. It's been triggered by issues like #13423 or #13897. This is not strictly a bug but potential root cause of stack size related issues. Especially, that prior that change, by default, log thread stack usage depended on external settings (platorm or presence of new_libc). |
Codecov Report
@@ Coverage Diff @@
## master #14036 +/- ##
==========================================
- Coverage 52.27% 52.24% -0.04%
==========================================
Files 307 307
Lines 45469 45469
Branches 10526 10526
==========================================
- Hits 23770 23754 -16
- Misses 16901 16913 +12
- Partials 4798 4802 +4
Continue to review full report at Codecov.
|
My only nit (and it's not a show stopper) is that we are now auto selecting a config with "DISABLE" in it.. sounds like a double negative. In a perfect world, the config would have been "ENABLE_FANCY_OUTPUT" and we leave it off by default. Still, with a fix to the commit title, LGTM. |
nordic-krch
force-pushed
the
log_use_vprintk_always
branch
from
17b78b8 to
6615390
Compare
Previously, _prf function was used when present and _vprintk was used otherwise. _prf supports reacher formatting but at cost of 3k flash and >250 bytes on stack. Stack usage then depended on which function was used and that was causing troubles when trimming stack sizes. Signed-off-by: Krzysztof Chruscinski <[email protected]>
nordic-krch
force-pushed
the
log_use_vprintk_always
branch
from
6615390 to
5731116
Compare
Previously, _prf function was used when present and _vprintk
was used otherwise. _prf supports reacher formatting but at
cost of 3k flash and >250 bytes on stack. Stack usage then
depended on which function was used and that was causing
troubles when trimming stack sizes.
Signed-off-by: Krzysztof Chruscinski [email protected]