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

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

On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
<sergey.senozhatsky@gmail.com> wrote:
>
> ok. that's something several people asked for -- some sort of buffered
> printk mode; but people don't want to use a buffer allocated on the stack
> (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> because this adds some extra cost:

I don't like the notion of per-cpu buffers either, because then you
suddenly get atomicity issues, and you really don't want that.

My preference as a user is actually to just have a dynamically
re-sizable buffer (that's pretty much what I've done in *every* single
user space project I've had in the last decade), but because some
users might have atomicity issues I do suspect that we should just use
a stack buffer.

And then perhaps say that the buffer size has to be capped at 80 characters.

Because if you're printing more than 80 characters and expecting it
all to fit on a line, you're doing something else wrong anyway.

And hide it not as a explicit "char buffer[80]]" allocation, but as a
"struct line_buffer" or similar, so that

 (a) people don't get the line size wrong

 (b) the buffering code can add a few fields for length etc in there too

Introduce a few helper functions for it:

 init_line_buffer(&buf);
 print_line(&buf, fmt, args);
 vprint_line(&buf, fmt, vararg);
 finish_line(&buf);

or whatever, and it sounds like it should be pretty easy to use.

                Linus