[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170901071340.19bd3f3e@gandalf.local.home>
Date: Fri, 1 Sep 2017 07:13:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Pavel Machek <pavel@....cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>, 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>
Subject: Re: printk: what is going on with additional newlines?
On Fri, 1 Sep 2017 09:29:06 +0200
Pavel Machek <pavel@....cz> wrote:
> Well, usually dev_info (and friends) is right thing to use for
> production. But very little debugging remains after the
> .. well.. debugging phase, so something that behaves similar to
> printf() is nice.
Try using trace_printk(). Who uses printk() to debug anymore ;-)
>
> Actually, I believe we should just create printf() in kernel. Its the
> mistake I do all the time.
It's a way to tell you how much user vs kernel programming you do. When
you type printk() in user space, you know you've been doing more kernel
programming. When you type printf() in kernel space, you've been doing
more user space programming.
-- Steve
Powered by blists - more mailing lists