From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754112AbcJHHgz (ORCPT ); Sat, 8 Oct 2016 03:36:55 -0400 Received: from smtprelay0039.hostedemail.com ([216.40.44.39]:58364 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750742AbcJHHgy (ORCPT ); Sat, 8 Oct 2016 03:36:54 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 30,2,0,,d41d8cd98f00b204,joe@perches.com,:::::::,RULES_HIT:41:355:379:541:599:800:960:968:973:981:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2691:2736:2828:3138:3139:3140:3141:3142:3291:3354:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4321:5007:6117:6691:7903:10010:10400:10848:11232:11658:11914:12043:12296:12438:12663:12740:12760:13161:13229:13439:14181:14659:14721:21080:21095:21326:21365:21433:21451:30012:30054:30060:30070:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:2:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: wash39_1eeac50308128 X-Filterd-Recvd-Size: 3474 Message-ID: <1475912203.2856.1.camel@perches.com> Subject: Re: [GIT PULL] trivial for 4.9 From: Joe Perches To: Linus Torvalds Cc: Jiri Kosina , Colin Ian King , Linux Kernel Mailing List Date: Sat, 08 Oct 2016 00:36:43 -0700 In-Reply-To: References: <1475870688.1945.13.camel@perches.com> <1475871538.1945.15.camel@perches.com> <1475872401.1945.17.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.22.0-2ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-10-07 at 14:37 -0700, Linus Torvalds wrote: > On Fri, Oct 7, 2016 at 2:06 PM, Linus Torvalds > wrote: > > > > And btw, even without an explicit KERN_, you should still not > > get any interleaving. Only an _explicit_ KERN_CONT should cause > > interleaving > > > Btw, note the "should" there. Because we do seem to have broken that > _again_. It worked fine at some point, but lookie here: > > commit 61e99ab8e35a88b8c4d0f80d3df9ee16df471be5 > Author: Joe Perches > Date: Mon Jul 30 14:40:21 2012 -0700 > > printk: remove the now unnecessary "C" annotation for KERN_CONT > > Now that all KERN_ uses are prefixed with ASCII SOH, there is no > need for a KERN_CONT. Keep it backward compatible by adding #define > KERN_CONT "" > > Joe, you *are* the problem here. > > So you are literally the person who broke this. > > Goddammit, I don't want to hear another peep from you. You broke this > because you wanted to save a few bytes in those strings, and then > *because* you broke it, you then argue for putting those bytes back in > the form of "\n" characters. > > Fuck me sideways. You make this big deal about how this interleaving > is a big problem, and at no point did you actually point to the real > issue, which was your very own breakage where you made it all fragile. The _only_ person that's making a "big deal" out of it is _you_. And I believe you are wrong here. Both about the original behavior and the effect of the change I made. I'm not swearing, I'm just commenting. In no case is a comment anything like a "big deal". And the only thing that commit did was avoid skipping forward in the format. It didn't have anything to do with interleaving. The logging code for v3.5 and v3.6, (pre and post this patch) both of which I just tested, emit these on a single line printk(KERN_INFO "format"); printk(" continued on the same line\n"); Same as pr_info("format"); pr_cont(" continued on the same line\n"); neither dmesg nor /dev/kmsg show any difference.