Re: printk: what is going on with additional newlines?
From: Joe Perches
Date: Fri Sep 01 2017 - 03:23:41 EST
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.