From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755877AbcJLQy1 (ORCPT ); Wed, 12 Oct 2016 12:54:27 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:33958 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755670AbcJLQyK (ORCPT ); Wed, 12 Oct 2016 12:54:10 -0400 MIME-Version: 1.0 In-Reply-To: <1476288961.16823.11.camel@perches.com> References: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> <1476288961.16823.11.camel@perches.com> From: Linus Torvalds Date: Wed, 12 Oct 2016 09:54:07 -0700 X-Google-Sender-Auth: cB4E86A9eb93C9LrVoViEx5tCNw Message-ID: Subject: Re: linux.git: printk() problem To: Joe Perches Cc: Tetsuo Handa , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches wrote: >> (but with the new world order you actually *can* combine KERN_CONT >> with a loglevel, so that if the beginning od the line got flushed, the >> continuation can still be printed with the right log level). > > I think that might not be a good idea. > > Anything that uses a KERN_CONT with a new log level > might as well be converted into multiple printks. Generally yes. The immediate reason for it was some really really nasty and horrible indirection in the ACPI layer, which goes through something like fifteen million different abstraction layers before it actually hits "printk()", and some of them do vsprintf() in the middle. It was something like ACPI_INFO() -> acpi_os_printf() -> acpi_os_vprintf() which is completely broken and *always* has that KERN_CONT marker at the beginning, but earlier phases can have the level marker in it already.. In other words, it was a terminally broken piece of nasty code, but there was no way I was going to touch the ACPI "OS independent" layers, so I just said "screw this, if you want to mix KERN_CONT with a level marker, you can". So I agree, you normally shouldn't need to. In fact, the fewer KERN_CONT's I see in the kernel, the better off we are. But _sometimes_ KERN_CONT makes sense (and the OOM code is likely one of the few places where it really might be the best of a number of bad options: lots of information that needs to be pretty dense, and we obviously can't afford to allocate a buffer for it dynamically, and doing so statically isn't a great option either..) Linus