[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwsj81i-AtuP76dxuhbU2fLYrJmx9h39NyQ=AAGueWHXg@mail.gmail.com>
Date: Tue, 5 Sep 2017 19:36:46 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Joe Perches <joe@...ches.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Pavel Machek <pavel@....cz>, Petr Mladek <pmladek@...e.com>,
Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Slaby <jslaby@...e.com>, Andreas Mohr <andi@...as.de>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: printk: what is going on with additional newlines?
On Tue, Sep 5, 2017 at 7:54 AM, Steven Rostedt <rostedt@...dmis.org> 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
markers.
Linus
Powered by blists - more mailing lists