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

[Joe Perches <joe@perches.com>]

On Tue, 2017-08-29 at 10:52 -0700, Linus Torvalds wrote:
> 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.

Mostly true and not a new solution.

You'll now need to add &buf to called functions that
continue individual line output.

Tejun Heo suggested the very similar mprintk back in 2008.

http://thread.gmane.org/gmane.linux.ide/27199