Re: printk: what is going on with additional newlines?

Pavel Machek
2017-09-01T07:29:09Z

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Fri 2017-09-01 10:40:12, Sergey Senozhatsky wrote:
> Hi,
>
> 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?
> > >
> > > 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...
>
> well... just a note, I personally developed a new habit - use
> pr_err/pr_cont/etc macros instead of explicit printk(KERN_FOO "...").
> may be this can work for you. and we _probably_ need to advertise
> pr_foo() more.

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.

Actually, I believe we should just create printf() in kernel. Its the
mistake I do all the time.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]