On Wed, 2016-03-02 at 01:29 +0000, Kalowsky, Daniel wrote:

-----Original Message-----
From: Saucedo Tejada, Genaro [mailto:genaro.saucedo.tejada(a)intel.co
m]
Sent: Tuesday, March 1, 2016 4:27 PM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>; Walsh, Benjamin
(Wind
River) <benjamin.walsh(a)windriver.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: RFC[2/2] Common logging infrastructure
and API

On Thu, 2016-02-25 at 07:54 -0800, Dirk Brandewie wrote:

On 02/25/2016 07:47 AM, Benjamin Walsh wrote:

On Thu, Feb 25, 2016 at 07:05:49AM -0800, Dirk Brandewie wrote:

On 02/24/2016 02:13 PM, Saucedo Tejada, Genaro wrote:

 From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17
00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.co
m>
Date: Fri, 19 Feb 2016 17:10:28 -0600
Subject: [PATCH] Log macros unified in a common API

Introduces a header to concentrate logging macro
definitions
for all
code to
reuse, change aims to provide all currently existing
logging
functionality so
every C file can replace it's compile-unit definitions by
common code.

Later enhancements to log can now be performed in a single
file.

Features:
* Optional printing of thread pointer
* Optional printing of colored messages
* Optional printing of a label to indicate logging level
(info,
error,
warning, debug)
* Caller function name printing
* Incremental log levels
* One point log disable

I like this in general we need a common set of debug output
macros
that all drivers can use.  Currently we have a *bunch* of
different
versions of the same thing in use throughout the driver tree.

I don't like the naming, we already have a kernel event
logging
API
people may assume that the two facilities are connected based
on
the name.

Can we change the names to debug_* or something else?

Although a namespace is needed (as noted bellow) debug is not the
only
goal of this infrastructure INFO and ERROR level might be used for
big
production environments in the future.

Can you share what a "production environment in the future" means?

<... snip ...>

I mean applications could rely on log API to report the most important
messages even in a complete application (that's what I meant by
production), it wouldn't make sense to expect a terminal in that case
but a rollover log on a file system could store these messages (future
work), in this case a developer wouldn't be debugging the application,
instead a user could be dealing with problems caused by external
factors or simply monitoring.

Other "logging" examples not exclusive to debugging were mentioned by
Anas in another thread: "...send messages to a remote endpoint or write
messages to a connected display".

I propose 'LOG_' as the prefix of all the function-like macros and
Kconfig variables, I'm using it for the improved patch set as place
holder anyway but expect to mass rename if, for example, it gets
decided to keep such name for the kernel event logger facility.

An actual name space would be needed for a run-time implementation
of a
more complex logging facility, such as sys_log() instead of printf.

Right.  I think you're overlooking that by selecting LOG_, you're
selecting the most obvious name for such a feature.  By doing
so,  you're now taking that namespace away from any application
developer.  This is why we are suggesting the macros and any code
functionality all start with the SYS_ prefix as that is already
reserved by the kernel.

Got it, will change it to 'SYS_LOG_'.