[lkml]   [2017]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: printk: what is going on with additional newlines?
On Tue, Sep 5, 2017 at 7:54 AM, Steven Rostedt <> wrote:
> You can do what I did with trace_printk(). I have a buffer per context.
> Then you only need to use preempt_disable() to do the print. That is,
> trace_printk() has 4 buffers:
> 1. Normal context
> 2. softirq context
> 3. irq context
> 4. NMI context

This is exactly what Tetsuo's code did (except he also added the
current thread context), and I already told people once in this thread
why that doesn't work.

It may be fine if you want to do CPU tracing, but it's not acceptable
for the whole line buffering.

If I'm printing out bytes of a hex buffer, and I have a bug, and take
a page fault, the context above doesn't change.

But I sure as #%!Ing hell don't want the page fault information
buffered with my hex bytes. They share no context at all.

So no. Stop this idiotic "implicit context". Get that disease off your
brain. It's wrong.

Either you guys are happy with the current line buffering, or you do
it with an explicit buffer context. No ifs, buts or idiotic context


 \ /
  Last update: 2017-09-06 04:37    [W:0.124 / U:5.488 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site