[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YujUOEVXYpZBq5jz@alley>
Date: Tue, 2 Aug 2022 09:37:28 +0200
From: Petr Mladek <pmladek@...e.com>
To: David Laight <David.Laight@...lab.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
John Ogness <john.ogness@...utronix.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Thomas Gleixner <tglx@...utronix.de>, Jan Kara <jack@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] printk for 5.20
On Mon 2022-08-01 15:45:13, David Laight wrote:
> > - Completely disable printing on consoles with CONFIG_RT. They break
> > RT guarantees. They are too slow to be called with raw spinlocks.
> > They can't be called with normal spinlocks in an atomic context because
> > RT spinlocks might sleep. It is going to get fixed by the kthreads and
> > atomic consoles. In the meantime, the debugging of CONFIG_RT kernel
> > will be possible only by the user space kernel log readers.
>
> SYSV used to be like that if you were running syslogd.
> Used to make debugging some issues completely impossible.
Sure. My understanding is that this is how RT guys want it in
4.19. There is no quick magic solution. Either printk() would break
RT guarantees or messages will not be seen on consoles. The blank
consoles were chosen as the least bad solution. Of course, we
are still working on the printk kthreads and atomic consoles
that would allow debugging using consoles on RT again.
Best Regards,
Petr
Powered by blists - more mailing lists