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

[Ingo Molnar <mingo@kernel.org>]

* Steven Rostedt <rostedt@goodmis.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