From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943450AbcJSOxu (ORCPT ); Wed, 19 Oct 2016 10:53:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:44242 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S943035AbcJSOxr (ORCPT ); Wed, 19 Oct 2016 10:53:47 -0400 Date: Wed, 19 Oct 2016 09:04:16 +0200 From: Jan Kara To: Peter Zijlstra Cc: Sergey Senozhatsky , Petr Mladek , Andrew Morton , Jan Kara , Tejun Heo , Calvin Owens , Thomas Gleixner , Mel Gorman , Steven Rostedt , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] make printk work again Message-ID: <20161019070416.GF29967@quack2.suse.cz> References: <20161018170830.405990950@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161018170830.405990950@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 18-10-16 19:08:30, Peter Zijlstra wrote: > This basically fixes printk by evading everything it does. > > There's too many problems with printk, from sleeping locks to broken console > drivers. Stop using it. I agree that printk is fragile and your patches are likely fine for machine where you do kernel development. However for production servers with hundreds of SCSI LUNs assigned I don't think it is a viable solution - I'm pretty sure those machines would take ages to boot (if they ever boot) with early_printk implementation. So do you intend this as "the ultimate printk solution" or just a "kernel developers debugging aid"? :) Honza -- Jan Kara SUSE Labs, CR