From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759063AbcJYOnL (ORCPT ); Tue, 25 Oct 2016 10:43:11 -0400 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.231]:64307 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758992AbcJYOnG (ORCPT ); Tue, 25 Oct 2016 10:43:06 -0400 Date: Tue, 25 Oct 2016 10:42:56 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Geert Uytterhoeven , Tetsuo Handa , Linux Kernel Mailing List Subject: Re: linux.git: printk() problem Message-ID: <20161025144256.ngfxchitby4xpxno@home.goodmis.org> References: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) X-RR-Connecting-IP: 107.14.168.6:25 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 23, 2016 at 11:11:18AM -0700, Linus Torvalds wrote: > > For example, one of the really historical uses for partial lines is this: > > pr_info("Checking 'hlt' instruction... "); > > if (!boot_cpu_data.hlt_works_ok) { > pr_cont("disabled\n"); > return; > } > halt(); > halt(); > halt(); > halt(); > pr_cont("OK\n"); > > and the point was that there used to be some really old i386 machines > that hung on the "hlt" instruction (probably not because of a CPU bug, > but because of either power supply issues or some DMA issues). > > To support that, we really *had* to print out the continuation lines > even when they were partial. And that complicates the printk logic a > lot. Note, my ftrace start up tests still does exactly this (e.g.): pr_info("Testing dynamic ftrace ops: #%d: ", cnt); [ do lots of testing ] printk(KERN_CONT "PASSED\n"); Previously a change was made to buffer lines without \n, and I wasted an entire day debugging why a crash happened because I was looking at the wrong test. -- Steve > > Now, that "hlt" case is long long gone, and maybe we should just say > "screw that". It would be really quite easy to say "we don't print out > continuation lines immediately, we just buffer them for 0.1s instead, > and KERN_CONT only works for things that really happen more or less > immediately". > > Maybe that really is the right answer. Because the original cause of > us having to bend over backwards in this case is really no longer > there. And it would simplify printk a *lot*. > > Let me whip up a minimal patch for you to try.