From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751512AbdIAH3J (ORCPT ); Fri, 1 Sep 2017 03:29:09 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45746 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751354AbdIAH3I (ORCPT ); Fri, 1 Sep 2017 03:29:08 -0400 Date: Fri, 1 Sep 2017 09:29:06 +0200 From: Pavel Machek To: Sergey Senozhatsky Cc: Linus Torvalds , Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Jan Kara , Andrew Morton , Jiri Slaby , Andreas Mohr , Tetsuo Handa , Linux Kernel Mailing List Subject: Re: printk: what is going on with additional newlines? Message-ID: <20170901072906.GB12104@amd> References: <20170815025625.1977-1-sergey.senozhatsky@gmail.com> <20170828090521.GA25025@amd> <20170829202447.GA20829@amd> <20170901014012.GA814@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <20170901014012.GA814@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri 2017-09-01 10:40:12, Sergey Senozhatsky wrote: > Hi, >=20 > On (08/29/17 22:24), Pavel Machek wrote: > > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce > > > > foo\nbar. That's... quite surprising/unwelcome. What is going on > > > > there? Are timestamps responsible? > > >=20 > > > No. > > >=20 > > > It's actively trying to treach you not to do shit. > > >=20 > > > If you want to continue a line, you NEED to use KERN_CONT. > > >=20 > > > That has always been true. It hasn't always been enforced, though. > >=20 > > Dumping hex buffer for debugging should not be a rocket science. You > > are welcome not add checkpatch rules to prevent such code from being > > merged... >=20 > well... just a note, I personally developed a new habit - use > pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "..."). > may be this can work for you. and we _probably_ need to advertise > pr_foo() more. Well, usually dev_info (and friends) is right thing to use for production. But very little debugging remains after the =2E. well.. debugging phase, so something that behaves similar to printf() is nice. Actually, I believe we should just create printf() in kernel. Its the mistake I do all the time. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlmpDEIACgkQMOfwapXb+vJRUQCghgsmE3iu4cBD5CaqiCPSqQvH a88AnjDtAgRuH2EHAuPfy8mB0U9tjngX =coSb -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp--