Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757228AbcJGXg4 (ORCPT ); Fri, 7 Oct 2016 19:36:56 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:36477 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753073AbcJGXgt (ORCPT ); Fri, 7 Oct 2016 19:36:49 -0400 MIME-Version: 1.0 In-Reply-To: References:

<1475870688.1945.13.camel@perches.com> <1475871538.1945.15.camel@perches.com> <1475872401.1945.17.camel@perches.com> <1475876667.1945.28.camel@perches.com>

From: Linus Torvalds Date: Fri, 7 Oct 2016 16:36:47 -0700 X-Google-Sender-Auth: DP-GoJGl599-ZwWBKHGLNBHFUKg Message-ID: Subject: Re: [GIT PULL] trivial for 4.9 To: Tony Luck Cc: Joe Perches , Jiri Kosina , Colin Ian King , 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 Content-Length: 2708 Lines: 53 On Fri, Oct 7, 2016 at 4:09 PM, Tony Luck wrote: > On Fri, Oct 7, 2016 at 4:01 PM, Tony Luck wrote: >> What if there isn't a "next printk" call for hours, or days? >> >> That poor little message without a "\n" will sit in the kernel buffers, >> and the user who might want to see the message can't, until some >> unrelated thing happens to print something. > > Retracted ... I'm sure that at some point in the past it happened > like that ... but I just retested on 4.8 and the first message (with > no "\n") showed up on the serial port just fine without some other > message to push it out. When the next message came along, a "\n" was > auto-inserted. Yeah, that immediate printout has actually always worked fine - the newline was never really a buffering thing. The buffering actually came fairly late, with the "newfangled" record-oriented logging facility (4+ years old by now). Our kernel message log was historically just a plain buffer, and not record-oriented at all. You'd just read and write it as a stream. In that historical context, it made tons of sense to just write something without a newline, and then continue writing on the same line: that's how always works. But back in 2012, Kay Sievers wanted to make it record-based, because reasons. That *really* doesn't play well with the whole "oh, you might not get the whole thing in one go" model, and things were broken a few times. It also made our printk implementation a lot more complex. But there was some argument for a full-featured syslog facility. Line continuations suddenly weren't very natural any more, because now a continuation printk was very much a "broken record". Anyway, the complexity has had upsides too, and the "let's not require '\n' at the end" actually came in through that (in fact, I think the record-based internal format removes the newlines at the end of characters). And there are some real advantages, both with timestamps and with having per-record log levels. So it's definitely not all bad, but there's a fair amount of complexity in there. The old model was rather broken in other ways, though, so on the whole I think we're doing fairly ok. But yes, the line continuation that *used* to be very natural (but always had problems with concurrent output from multiple contexts) definitely makes for extra complexity in the record-based model. But exactly *because* the record-based thing needs to be more careful about those newlines, it actually ended up being why the explicit "\n" thing at the end of a printk shouldn't really matter any more. And not having it does make for nicer printk strings. "Just the facts". Linus