lkml.org 
[lkml]   [2017]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: printk: what is going on with additional newlines?
From
Date
On Fri, 2017-09-01 at 08:59 +0200, Pavel Machek wrote:
> On Thu 2017-08-31 19:04:24, Joe Perches wrote:
> > On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> > > 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?
> > []
> > > > You are welcome not add checkpatch rules to prevent such code from being
> > > > merged...
> >
> > Pavel, what does this mean?
> That should have been "welcome to".

Right.

Good luck with a checkpatch implementation.

> IMO pr_foo() is bad interface for debugging.

Why?

> I just want to see the data... and difference
> from userspace debugging actually hurts there.

How so? What data is not available?

Making functions of the various pr_<level> uses
makes it easier to insert things like singletons
for any pr_fmt prefix which could save a few KB
and as well allow for centralized mechanisms to
emit logging messages with
%ps, __builtin_return_address(0)
instead of using
"%s <fmt>", __func__, args...
to save even more space.

\
 
 \ /
  Last update: 2017-09-01 09:23    [W:0.107 / U:2.312 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site