linux-kernel - Re: [PATCH v2] printk: Have printk() never buffer its data

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] [day] [month] [year] [list]

Date:	Tue, 26 Jun 2012 22:43:58 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Kay Sievers <kay@...y.org>, LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v2] printk: Have printk() never buffer its data


* Steven Rostedt <rostedt@...dmis.org> wrote:

> >  It also sounds like quite a lot of wasted headers in the 
> > buffer, which we need to carry around and throw away when we 
> > reconstruct the line for output again. If we merge them 
> > internally we mess around with the sequence numbers, if we 
> > merge them in userspace we would need to export the flags to 
> > do that.
> 
> As I'm still on debian and fedora 14, I have to admit that I 
> do not quite understand exactly what you are trying to do with 
> systemd or your logging facility. But it seems to become clear 
> that printk isn't a tool for it.
> 
> What exactly are you trying to record from the kernel? Device 
> information, kernel diagnostics, or something else? Maybe 
> there should be another facility besides printk that can pass 
> what you want to your utilities.
> 
> printk is the first line of attack for kernel developers to 
> find their bugs. If it becomes bloated and focused on users, 
> it will make development of the kernel much more difficult.
> 
> Perhaps we should have added a hook or a tracepoint at the 
> beginning of printk that your logging facility could attach 
> to, [...]

That was my immediate suggestion very early on in the printk 
discussion, months ago, when Kay was still giving us nightmares 
about UUID printk's and other nonsense.

Adding the printk tracepoint and feeding it to kmesg would have 
been a few trivial lines of code plus tracing code reuse, it 
would have made a ton of sense and it would have enhanced 
tracing and profiling as well, not just kmdesg/syslogd-ng.

I guess the triviality of it must have been one of the reasons 
why it wasn't implemented that way ;-)

Today I'd be happy with at least having clean separation of a 
direct, relatively simple printk() from whatever special purpose 
new logging facilities feed off of printk().

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/