lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] printk: support structured and multi-facility log messages
On Thu, Apr 5, 2012 at 17:05, Ingo Molnar <mingo@kernel.org> wrote:
> * Kay Sievers <kay@vrfy.org> wrote:

>> - Record-based stream instead of the traditional byte stream
>>   buffer. All records carry a 64 bit timestamp, the syslog facility
>>   and priority in the record header.

> Hm, this seems to be a conceptual duplication of the console
> tracepoint that include/trace/events/printk.h already offers.

General purpose kernel logging should not depend on _optional_
facilities mainly intended for debugging and profiling. This is stuff
that should be used on every box out there, very much much unlike
tracing.

I can understand that you propose the trace things, but I'm not
convinced that tracing is the same as system logging, or it will ever
become it.

Tracing is either duplicating everything in the kmsg buffer, or it
will possibly provide dangling pointers into it. Both doesn't sound
too convincing. If printk_time is used, you can even store more
messages in the same buffer as today.

The added code is less than 100 lines, if you remove the export to
/dev/kmsg. We get what we are looking for basically for free, without
to mandate any additional subsystem to built into the kernel/.

I doubt we can here talk about "yet another logging"; it is exactly
the intention _not _ to have another copy of the same data, like
tracing would introduce. This is just an improved version of the good
old kmsg buffer without really changing its interface.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-04-05 17:29    [from the cache]
©2003-2011 Jasper Spaans