linux-kernel - Re: printk: what is going on with additional newlines?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Aug 2017 11:09:20 -0700
From:   Joe Perches <joe@...ches.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Tejun Heo <tj@...nel.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Pavel Machek <pavel@....cz>, Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jiri Slaby <jslaby@...e.com>, Andreas Mohr <andi@...as.de>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: printk: what is going on with additional newlines?

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@...il.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