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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, Sep 1, 2017 at 11:12 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> I just tried to distinguish context using one "unsigned long" value
> by embedding IRQ status into lower bits of "struct task_struct *".
> I can change to distinguish context using multiple "unsigned long" values.

I really really don't think we want to use implicit contexts. I
suspect you'd end up doing something like a per-cpu counter (with
perhaps the CPU number in the low bits or something) and every
exception and sw interrupt etc would increment it.

.. oh, and workqueues etc.

And the end result would be that you'd be very limited in where you
can actually expect buffering to happen.

Which is all a bad design, since just making the buffer explicit is
(a) cheaper and (b) better. Now you can put the buffer on the stack,
you never have to worry about where you need to track context, and you
have no buffering limits (ie you can buffer across any event).

> If my assumption was wrong, isn't it dangerous from stack usage point of
> view that we try to call kmalloc()

I think there might be situations where you want to do that, but since
we're talking _printing_, we also know that the buffering normally is
about a single line.

Sure, some situations might want to buffer more before they print out
(perhaps you want to have guarantees that the register state of an
oops never gets mixed up with anything else, or whatever), and maybe
sometimes you'd want bigger lines.

But I definitely suspect that "single line" is often sufficient. I
mean, that's all that KERN_CONT ever gave you anyway (and not
reliably).

And then a 80 character buffer really isn't any different from having
a structure with a few pointers in it, which we do on the stack all
the time.

                  Linus