Messages in this thread | | | Subject | Re: printk: what is going on with additional newlines? | From | Joe Perches <> | Date | Fri, 01 Sep 2017 00:23:33 -0700 |
| |
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.
| |