Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751345Ab2EIE1f (ORCPT ); Wed, 9 May 2012 00:27:35 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:52198 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758Ab2EIE1e (ORCPT ); Wed, 9 May 2012 00:27:34 -0400 MIME-Version: 1.0 In-Reply-To: References: <1336004953.4240.9.camel@mop> <1336475689.1179.12.camel@mop> From: Linus Torvalds Date: Tue, 8 May 2012 21:27:12 -0700 X-Google-Sender-Auth: nMipMU1p5zmD6kFTGqNVa9j2I00 Message-ID: Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer To: Sasha Levin Cc: Kay Sievers , Greg Kroah-Hartmann , Ingo Molnar , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1201 Lines: 29 On Tue, May 8, 2012 at 9:11 PM, Sasha Levin wrote: > > Is there a reason to keep KERN_CONT under this set of rules at all? Yes, a very subtle and rare one. If you want to print out a string that starts with "<%d>", you *have* to use a prefix, in order to not make printk think that the "<*>" is the prefix itself. And if you don't want to start a new line, you need to use KERN_CONT. So there is *one* case, and one case only, where KERN_CONT is useful, and it's when the string you are printing out could otherwise be mistaken for a prefix itself (the "<%d>" thing isn't the only such string, of course - it could be a "%s" where the string has those characters in it. So think of KERN_CONT as a "quoting safety" thing. And in 99% of all cases it is obviously not actually needed. So in general, KERN_CONT is useless and should not be used, but that doesn't mean that it can be removed as a _concept_. Linus -- 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/