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 19:18:38 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Kay Sievers <kay@...y.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

* Kay Sievers <kay@...y.org> wrote:

> 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.

Firstly, you modify printk() and make it less simple and break 
its ASCII oriented nature - which is my primary objection: if 
you want to emit binary data then use existing binary logging 
facilities.

If you want to extend the ASCII output then work in the ASCII, 
human readable space and improve it.

If you want binary record logging (I'm not convinced printk() 
should do that, btw. - we are keeping it ASCII for damn good 
reasons), use perf software events - check your kernel, those 
are enabled more widely than even CONFIG_PRINTK is enabled - so 
your whole "but I don't want to rely on a non-generic facility" 
objection is bogus: perf events, if you decide to use them, are 
as generic as it gets.

So unless you have better justification for it than what you 
listed so far, or unless you have a better implementation that 
either goes into the better binary logging or into the better 
ASCII logging direction:

NAcked-by: Ingo Molnar <mingo@...nel.org>

Because this one is neither.

Thanks,

	Ingo
--
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/