From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751258AbdH2RAU (ORCPT ); Tue, 29 Aug 2017 13:00:20 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:32893 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750796AbdH2RAS (ORCPT ); Tue, 29 Aug 2017 13:00:18 -0400 MIME-Version: 1.0 In-Reply-To: <20170829134048.GA437@jagdpanzerIV.localdomain> References: <20170815025625.1977-1-sergey.senozhatsky@gmail.com> <20170828090521.GA25025@amd> <20170828102830.GA403@jagdpanzerIV.localdomain> <20170828122109.GA532@jagdpanzerIV.localdomain> <20170828124634.GD492@amd> <20170829134048.GA437@jagdpanzerIV.localdomain> From: Linus Torvalds Date: Tue, 29 Aug 2017 10:00:15 -0700 X-Google-Sender-Auth: -Wi6ywGOxLM3ZZbpxlTmS64nY94 Message-ID: Subject: Re: printk: what is going on with additional newlines? To: Sergey Senozhatsky Cc: Pavel Machek , Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Jan Kara , Andrew Morton , Jiri Slaby , Andreas Mohr , 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 Tue, Aug 29, 2017 at 6:40 AM, Sergey Senozhatsky wrote: > Pavel reported that > printk("foo"); printk("bar"); > > now does not produce a single continuation "foobar" line, but > instead produces two lines > foo > bar And that's the *correct* behavior. Stop trying to fix that. Fix the printk's instead. In particular, the printk("bar"); could have come from an interrupt, and have nothing what-so-ever to do with "foo". If you want continuations, you (a) make sure the first one doesn't end in a newline (b) make sure the second printk has a KERN_CONT (c) even after that, ask yourself how much you _really_ want continuations, because there are going to be situations where it still doesn't work. I refuse to help those things. We mis-designed things, and the continuations were a mistake to begin with, but they were a mistake that was understandable in the timeframe they happened. But it's not something we should support, and it's most definitely is not something we should then say "oh, you were broken shit that didn't even bother to add the KERN_CONT, let me help your crap". No. Only acceptable use of continuations is basically boot-time testing, when you do things like printk("Testing feature XYZ.."); this_may_blow_up_because_of_hw_bugs(); printk(KERN_CONT " ... ok\n"); and anything else you should seriously try to marshal the data *before* doing a printk(), and not expect printk() to marshal it for you. But for legacy reasons, we do end up trying to support KERN_CONT. Just barely. I'd really like to get rid of it entirely, because the whole log-based structure really really doesn't work well for it (what if somebody has already read the partial line from the logs?) Our printk stuff didn't used to be log-based. It was just a plain character-based circular buffer. Back then that KERN_CONT made a whole lot more sense. Linus