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

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2012-06-25 at 17:22 +0200, Kay Sievers wrote:
> On Mon, Jun 25, 2012 at 4:26 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Mon, 2012-06-25 at 15:56 +0200, Ingo Molnar wrote:
> 
> >> Anyway, bike shed painting aside, the patch looks like a
> >> workable solution to me.
> >
> > Great! Lets hope Kay feels the same way.
> 
> Hmm, what I still miss, is how the log record export should work
> properly with unbuffered continuation lines.
> 
> The buffering of continuation line users resulted in a clean one
> record per logged line. Now we will get all separated records for all
> continuation prints of a single line, which would either need to be
> merged in userspace, or internally.

Merge it in userspace.

> 
> Non-buffered continuation lines and and a record buffer don't play
> that well with each other.

Yeah, I know, as they seem to be a problem together in the coding.

>  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, and then it could do
logging and buffering in any manner it would like, instead of hijacking
the best debugging tool that kernel developers use.

I'm starting to side with Ingo that the new printk should be reverted
and rethought, and find another answer to the fixes that it solved.

-- Steve