Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751194Ab2EIEMO (ORCPT ); Wed, 9 May 2012 00:12:14 -0400 Received: from mail-yx0-f174.google.com ([209.85.213.174]:39795 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800Ab2EIEMN convert rfc822-to-8bit (ORCPT ); Wed, 9 May 2012 00:12:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <1336004953.4240.9.camel@mop> <1336475689.1179.12.camel@mop> From: Sasha Levin Date: Wed, 9 May 2012 06:11:51 +0200 Message-ID: Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer To: Linus Torvalds Cc: Kay Sievers , Greg Kroah-Hartmann , Ingo Molnar , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1250 Lines: 30 On Wed, May 9, 2012 at 5:52 AM, Linus Torvalds wrote: > KERN_CONT should not be needed if the previous printk didn't have a final "\n". > > We made it easier to use printk for a reason a few months ago. The new > rules are: > > ?- If you have a KERN_, it *always* starts a new line, the > obvious exception being KERN_CONT > > ?- the loglevels *only* matter at the start of the printk - so if you > have '\n' embedded in a single printk, that changes nothing > what-so-ever. It's not line-based. > > ?- if you didn't have a '\n', and don't have a loglevel, KERN_CONT is implied. > > Quite frankly, those three rules (a) make sense and (b) make things easy. Is there a reason to keep KERN_CONT under this set of rules at all? I'm guessing that there are very few places that have a final '\n' but still want to use KERN_CONT, and even in that case it should be trivially easy to fix them up. Besides that, from what I understand, KERN_CONT isn't really needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/