linux-kernel - Re: [PATCH] printk: support structured and multi-facility log messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Apr 2012 17:25:51 +0200
From:	Kay Sievers <kay@...y.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] printk: support structured and multi-facility log messages

On Thu, Apr 5, 2012 at 17:05, Ingo Molnar <mingo@...nel.org> wrote:
> * Kay Sievers <kay@...y.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/