We need to make sure we support logging for more than debugging andSo this works for a simple case. Can you expand on this for a more
during development. In most cases logging will be used during development
to assist with debugging and printing information on the console, however,
we need to make sure this design also addresses cases where logging is part
of the application, for example you might want to write to a file-system, send
messages to a remote endpoint or write messages to a connected display.
This basically means we also need to support different backends, the most
immediate and straightforward backend would be printing to the console
using printk and printf.
An application should be able to configure the domains and levels it wants to
log, for example, if I am debugging an issue with I2C and I am only interested
in I2C, I want to be able to select this domain and the logging level, so for
would enable logging (INFO) for everything using printk
For the case above I would change the following in my application .config:
complex case? For example, let's take debugging the Galileo 2 pinmux,
which has dependencies on I2C, GPIO, and the Pinmux. How would you
setup the DOMAINs value then and parse it?
I agree this sounds awkward.
Why aren't the component themselves providing a kconfig option that can
be tweaked on a per-component basis.
This allows individual files to be compiled with different log levels by
doing this in their implementation:
#define SYS_LOG_LEVEL CONFIG_I2C_LOG_LEVEL
#define SYS_LOG_LEVEL CONFIG_PWM_LOG_LEVEL
in, well, all kernel files (or some common kernel-only header file):
#define SYS_LOG_LEVEL CONFIG_KERNEL_LOG_LEVEL
Basically, this allow each subsystem to drive the logging.h logic
differently. You might not want "DEBUG" level across the whole system
because of too much verbosity, but you'd still like to have "ERROR"
level everywhere while debugging one subsystem.