[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200424103131.7987f890@gandalf.local.home>
Date: Fri, 24 Apr 2020 10:31:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
Michal Hocko <mhocko@...e.com>,
Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".
On Fri, 24 Apr 2020 23:00:01 +0900
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote:
> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
> sleep has failed), we can't create buffer on demand. For process context, it
> would be possible to create buffer upon fork() time. But for atomic context,
> it is so difficult to create buffer on demand. We could allocate shared buffer
> like logbuf but it means that we have to replicate what printk() is doing (too
> much code), for when atomic memory allocation happens resembles when printk()
> is called. Borrowing printk()'s logbuf is simpler.
I would have a buffer allocated for this at start up.
What exactly would you be "replicating" in printk? The point of printk is
to print to a console, not to be a generic ring buffer. This change is
breaking printk's most useful feature.
-- Steve
Powered by blists - more mailing lists