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

Linus Torvalds
2017-08-29T17:00:20Z

On Tue, Aug 29, 2017 at 6:40 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> Pavel reported that
> printk("foo"); printk("bar");
>
> now does not produce a single continuation "foobar" line, but
> instead produces two lines
> foo
> bar

And that's the *correct* behavior.

Stop trying to fix that. Fix the printk's instead.

In particular, the

printk("bar");

could have come from an interrupt, and have nothing what-so-ever to do
with "foo".

If you want continuations, you

(a) make sure the first one doesn't end in a newline

(b) make sure the second printk has a KERN_CONT

(c) even after that, ask yourself how much you _really_ want
continuations, because there are going to be situations where it still
doesn't work.

I refuse to help those things. We mis-designed things, and the
continuations were a mistake to begin with, but they were a mistake
that was understandable in the timeframe they happened. But it's not
something we should support, and it's most definitely is not something
we should then say "oh, you were broken shit that didn't even bother
to add the KERN_CONT, let me help your crap".

No.

Only acceptable use of continuations is basically boot-time testing,
when you do things like

printk("Testing feature XYZ..");
this_may_blow_up_because_of_hw_bugs();
printk(KERN_CONT " ... ok\n");

and anything else you should seriously try to marshal the data
*before* doing a printk(), and not expect printk() to marshal it for
you. But for legacy reasons, we do end up trying to support KERN_CONT.
Just barely.

I'd really like to get rid of it entirely, because the whole log-based
structure really really doesn't work well for it (what if somebody has
already read the partial line from the logs?)

Our printk stuff didn't used to be log-based. It was just a plain
character-based circular buffer. Back then that KERN_CONT made a whole
lot more sense.

Linus