[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1908100745260.7324@nanos.tec.linutronix.de>
Date: Sat, 10 Aug 2019 07:53:56 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Peter Zijlstra <peterz@...radead.org>,
John Ogness <john.ogness@...utronix.de>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Brendan Higgins <brendanhiggins@...gle.com>
Subject: Re: [RFC PATCH v4 9/9] printk: use a new ringbuffer implementation
On Fri, 9 Aug 2019, Linus Torvalds wrote:
> On Thu, Aug 8, 2019 at 11:14 PM Peter Zijlstra <peterz@...radead.org> wrote:
> > Note that you can hook this into printk as a fake early serial device;
> > just have the serial device write to the DRAM buffer.
>
> No, you really really can't.
...
> Even the "early console" stuff tries to honor serialization by
> console_lock and console_suspended etc. Or things like the "I'm in the
> middle of the scheduler, so I won't be doing any real logging".
If you think of it as the classic console you are right. What Peter has in
mind is the extra stuff on top of this buffer patchset, which implements
emergency write to consoles. That's an extra callback in the console
struct, which can be invoked in such situations igoring context and console
lock completely.
Right now we have an implementation for serial only, but that already is
useful. I nicely got (minimaly garbled) crash dumps out of an NMI
handler. With the current mainline console code the machine just hung.
So with this scheme we actually could hook your smart buffer into the
console stuff and still achieve what you want.
Thanks,
tglx
Powered by blists - more mailing lists