From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751304AbdH2RhQ (ORCPT ); Tue, 29 Aug 2017 13:37:16 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:36398 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbdH2RhO (ORCPT ); Tue, 29 Aug 2017 13:37:14 -0400 Date: Wed, 30 Aug 2017 02:33:14 +0900 From: Sergey Senozhatsky To: Linus Torvalds Cc: Sergey Senozhatsky , Pavel Machek , Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Jan Kara , Andrew Morton , Jiri Slaby , Andreas Mohr , Tetsuo Handa , Linux Kernel Mailing List Subject: Re: printk: what is going on with additional newlines? Message-ID: <20170829173314.GA623@tigerII.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On (08/29/17 10:00), Linus Torvalds wrote: > 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. ok. thanks for taking a look. > 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. yes, continuations are not really welcomed. I thought that this particular case could be considered a regression. but your position is pretty clear. > 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. ok. that's something several people asked for -- some sort of buffered printk mode; but people don't want to use a buffer allocated on the stack (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"), because this adds some extra cost: void foo(void) { char cont_string[256]; size_t sz; sz = sprintf(cont_string + sz, "%xxxx", data1...); do_abc() sz += sprintf(cont_string + sz, "%xxxx", data1...); .... printk("%s\n", cont_string) // does "sprintf" again // and then memcpy } I thought about re-using printk-safe per-CPU buffers for that purpose. this saves us memory, because printk-safe buffers are always there, but it has some disadvantages. namely, to use printk-safe buffer we need to disable local interrupts. so something like this printk_buffered_mode_begin(); // disables local irq printk() // appends data to the per-CPU buffer printk() printk() printk_buffered_mode_end(); // append messages to consequent logbuf // entries // enable local irqs. ... not sure, how usable this will end up to be. probably not usable at all. > 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. -ss