On Tue, 2017-08-29 at 10:52 -0700, Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky > <[email protected]> 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
