[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170829202447.GA20829@amd>
Date: Tue, 29 Aug 2017 22:24:48 +0200
From: Pavel Machek <pavel@....cz>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Slaby <jslaby@...e.com>, Andreas Mohr <andi@...as.de>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: printk: what is going on with additional newlines?
Hi!
> > 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?
>
> No.
>
> It's actively trying to treach you not to do shit.
>
> If you want to continue a line, you NEED to use KERN_CONT.
>
> That has always been true. It hasn't always been enforced, though.
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...
> Stop doing continuations at all please. But if you do, you'd better
> use KERN_CONT. And if you don't, and you get multiple lines, it's your
> own damn fault.
..but please don't make debugging harder than it already is. Just
because you spend too much time doing kernel does not mean that
everyone is; having to remember "this is kernel, so it has to be
special, you have to do printk, not printf" is bad enough, having
different semantics is even more ugly.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists