On Mon, 2016-02-29 at 12:48 -0500, Benjamin Walsh wrote:
We need to make sure we support logging for more than debugging
during development. In most cases logging will be used during
to assist with debugging and printing information on the console,
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
messages to a remote endpoint or write messages to a connected
This basically means we also need to support different backends,
immediate and straightforward backend would be printing to the
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
in I2C, I want to be able to select this domain and the logging
level, so for
I agree this sounds awkward.
CONFIG_LOG_DOMAINS=“*”So this works for a simple case. Can you expand on this for a more
would enable logging (INFO) for everything using printk
For the case above I would change the following in my application
complex case? For example, let's take debugging the Galileo 2
which has dependencies on I2C, GPIO, and the Pinmux. How would you
setup the DOMAINs value then and parse it?
Why aren't the component themselves providing a kconfig option that
be tweaked on a per-component basis.
This allows individual files to be compiled with different log levels
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.
I'm supporting this now and will implement this on some reference
module as example for the following patch set.