When CONFIG_LOG_OUTPUT is set, it indicates that logging strings
are formatted by the application (using log_output module). It is
not needed when backend works in the dictionary mode. So far
LOG_OUTPUT was set also when dictionary mode was used and that
prevented removing of the logging strings from binary which is
an important feature of the dictionary logging.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The `LOG_BACKEND_FORMAT_TIMESTAMP` Kconfig currently depends on
a list of hardcoded backends.
Let's modify it to depend on an intermediary Kconfig
`LOG_BACKEND_SUPPORTS_FORMAT_TIMESTAMP` instead, which can be
selected by a OOT log backend.
Updated all exisitng supported backends to select this new
Kconfig.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
The RTT backend of the shell does not support several of the more
advanced terminal features. This commit proposes to inactivate these
features by default when RTT is selected as shell backend.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
As written, the title and description of the Kconfig option seem to
specify the logging sub-system will not flush until the buffer is full.
Someone reading this would expect that shorter log message will not be
flushed until the specified number of bytes accumulate.
This is not the case. Each log message is flushed when finished. The
size is only the maximum bytes of a single formatted message's contents
that will be accumated before the backend flushes.
What's more, it only applies in deferred mode. In immediate mode there
is no buffering, not just of multiple log messages but also of the
message contents as they are formatted.
Signed-off-by: Trent Piepho <tpiepho@gmail.com>
This allows putting the UART backend on a serial device that has to be
quiet unless logging is explicitly enabled at runtime.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
This is mainly to reduce clutter in `subsys/logging`, but also to make
backend management slightly easier.
Signed-off-by: Christopher Friedt <cfriedt@fb.com>
