Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755309AbcJGTXJ (ORCPT ); Fri, 7 Oct 2016 15:23:09 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:36626 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752180AbcJGTXA (ORCPT ); Fri, 7 Oct 2016 15:23:00 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Fri, 7 Oct 2016 12:22:59 -0700 X-Google-Sender-Auth: LiqGZWMdEu8B8NRYeNum93bJc_I Message-ID: Subject: Re: [GIT PULL] trivial for 4.9 To: Jiri Kosina , Colin Ian King Cc: 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: 1069 Lines: 26 On Fri, Oct 7, 2016 at 1:51 AM, Jiri Kosina wrote: > Colin Ian King (5): > netfilter: Add missing \n to pr_err() message > agp/intel: add missing \n to end of dev_emerg message > lightnvm: add missing \n to end of dev_err message > nvme: add missing \n to end of dev_warn message We really shouldn't be needing these final '\n' characters any more, afaik. If the next printk isn't done by the same process, and doesn't have a KERN_CONT, the printk machinery should add the newline on its own. I realize that people have been adding these '\n' characters for a while, but is there actually any point to it? They make the code less legible, imho. And we actually have a number of logging functions that explicitly don't want the newline (eg ext4_warning/error()), so it's actually more consistent to *not* have a newline than it is to have one. And if those '\n' characters actually make a difference, that should be noted. Because that would imply that the printk logic isn't working right. Hmm? Linus