Re: RFC[1/2] Common logging infrastructure and API

Nashif, Anas

On 29/02/2016, 12:48, "Benjamin Walsh" <benjamin.walsh(a)> wrote:

We need to make sure we support logging for more than debugging and
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

the defaults:


would enable logging (INFO) for everything using printk

For the case above I would change the following in my application .config:

So this works for a simple case. Can you expand on this for a more
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:

in i2c.c:
#include <logging.h>

in pwm.c:
#include <logging.h>

in, well, all kernel files (or some common kernel-only header file):
#include <logging.h>

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.

My 0.02$.

This sounds more scalable, basically removes the need for defining a domain and using the levels to do the selection of how verbose messages are for each domain.


Join to automatically receive all group messages.