From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Senozhatsky Subject: Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread Date: Mon, 4 Mar 2019 20:07:03 +0900 Message-ID: <20190304110703.GA960@tigerII.localdomain> References: <20190212143003.48446-1-john.ogness@linutronix.de> <20190212143003.48446-9-john.ogness@linutronix.de> <20190304073856.GA552@jagdpanzerIV> <20190304100044.GC21004@jagdpanzerIV> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190304100044.GC21004@jagdpanzerIV> Sender: linux-kernel-owner@vger.kernel.org To: John Ogness Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Petr Mladek , Steven Rostedt , Daniel Wang , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , Alan Cox , Jiri Slaby , Peter Feiner , linux-serial@vger.kernel.org, Sergey Senozhatsky , Sergey Senozhatsky List-Id: linux-serial@vger.kernel.org On (03/04/19 19:00), Sergey Senozhatsky wrote: > > But in general, channels which depend on preemptible printk will become > totally useless in some cases. > Which brings me to a question - what are those messages/channels? Not important enough to be printed on consoles immediately, yet important enough to pass the suppress_message_printing() check. We may wave those semi-important messages good bye, I'm afraid, preemptible printk will take care of it. So... do we have a case here? Do we really need printk-kthread? -ss