-----Original Message-----
From: Saucedo Tejada, Genaro [mailto:genaro.saucedo.tejada(a)intel.com]
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.com>
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 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.