900f9c3b24
Extend frontend API with optional set of functions which can be used when simplified log message handling is enabled. If this mode is enabled then there are dedicated macros for processing the most common messages (string + 0-2 word arguments). Using this API can speed up the processing of messages that are the most common. Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
76 lines
2.4 KiB
Plaintext
76 lines
2.4 KiB
Plaintext
# Copyright (c) 2021 Nordic Semiconductor ASA
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
choice LOG_MODE
|
|
prompt "Mode"
|
|
depends on !LOG_FRONTEND_ONLY
|
|
default LOG_MODE_MINIMAL if LOG_DEFAULT_MINIMAL
|
|
default LOG_MODE_DEFERRED
|
|
|
|
config LOG_MODE_DEFERRED
|
|
bool "Deferred logging"
|
|
select MPSC_PBUF
|
|
help
|
|
Log messages are buffered and processed later. This mode has the
|
|
least impact on the application. Time consuming processing is
|
|
deferred to the known context.
|
|
|
|
config LOG_MODE_IMMEDIATE
|
|
bool "Synchronous"
|
|
help
|
|
When enabled log is processed in the context of the call. It impacts
|
|
performance of the system since time consuming operations are
|
|
performed in the context of the log entry (e.g. high priority
|
|
interrupt).Logger backends must support exclusive access to work
|
|
flawlessly in that mode because one log operation can be interrupted
|
|
by another one in the higher priority context.
|
|
|
|
config LOG_MODE_MINIMAL
|
|
bool "Minimal-footprint"
|
|
select PRINTK
|
|
help
|
|
Enable minimal logging implementation. This has very little footprint
|
|
overhead on top of the printk() implementation for standard
|
|
logging macros. Hexdump macros are also supported, with a small
|
|
amount of code pulled in if used. Build time filtering is supported,
|
|
but not runtime filtering. There are no timestamps, prefixes,
|
|
colors, or asynchronous logging, and all messages are simply
|
|
sent to printk().
|
|
|
|
endchoice
|
|
|
|
config LOG_FRONTEND
|
|
bool "Frontend"
|
|
help
|
|
When enabled, logs are redirected to a custom frontend which is the
|
|
fastest way of getting logs out. The logs are redirected at the function
|
|
level. To redirect logs at the macro level, see LOG_CUSTOM_HEADER.
|
|
|
|
config LOG_FRONTEND_ONLY
|
|
bool "No backends"
|
|
depends on LOG_FRONTEND
|
|
help
|
|
Option indicates that there are no backends intended to be used.
|
|
Code asserts if any backend is enabled.
|
|
|
|
config LOG_FRONTEND_OPT_API
|
|
bool "Frontend optimized API"
|
|
help
|
|
When enabled, frontend implements functions which are optimized versions
|
|
used for the most common log messages.
|
|
|
|
config LOG_CUSTOM_HEADER
|
|
bool "Include Custom Log Header"
|
|
help
|
|
When enabled, a custom application provided header, named
|
|
"zephyr_custom_log.h", is included at the end of log.h. This enables
|
|
extension of the LOG_* APIs at the macro level. Please use cautiously!
|
|
The internal LOG API may change in future releases.
|
|
|
|
config LOG_DEFAULT_MINIMAL
|
|
bool
|
|
|
|
config LOG_MULTIDOMAIN
|
|
bool "Multi-domain logger"
|
|
select LOG_TIMESTAMP_64BIT
|