On Wed, 2016-03-02 at 01:29 +0000, Kalowsky, Daniel wrote:
-----Original Message-----Can you share what a "production environment in the future" means?
From: Saucedo Tejada, Genaro [mailto:genaro.saucedo.tejada(a)intel.co
Sent: Tuesday, March 1, 2016 4:27 PM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>; Walsh, Benjamin
Subject: [devel] Re: Re: Re: RFC[2/2] Common logging infrastructure
On Thu, 2016-02-25 at 07:54 -0800, Dirk Brandewie wrote:
Although a namespace is needed (as noted bellow) debug is not the
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 17I like this in general we need a common set of debug output
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.co
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
reuse, change aims to provide all currently existing
every C file can replace it's compile-unit definitions by
Later enhancements to log can now be performed in a single
* Optional printing of thread pointer
* Optional printing of colored messages
* Optional printing of a label to indicate logging level
* Caller function name printing
* Incremental log levels
* One point log disable
that all drivers can use. Currently we have a *bunch* of
versions of the same thing in use throughout the driver tree.
I don't like the naming, we already have a kernel event
people may assume that the two facilities are connected based
Can we change the names to debug_* or something else?
goal of this infrastructure INFO and ERROR level might be used for
production environments in the future.
<... 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 andRight. I think you're overlooking that by selecting LOG_, you're
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
more complex logging facility, such as sys_log() instead of printf.
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_'.