[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190906090627.GX2386@hirez.programming.kicks-ass.net>
Date: Fri, 6 Sep 2019 11:06:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Petr Mladek <pmladek@...e.com>
Cc: John Ogness <john.ogness@...utronix.de>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Brendan Higgins <brendanhiggins@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v4 0/9] printk: new ringbuffer implementation
On Thu, Sep 05, 2019 at 04:31:18PM +0200, Peter Zijlstra wrote:
> So I have something roughly like the below; I'm suggesting you add the
> line with + on:
>
> int early_vprintk(const char *fmt, va_list args)
> {
> char buf[256]; // teh suck!
> int old, n = vscnprintf(buf, sizeof(buf), fmt, args);
>
> old = cpu_lock();
> + printk_buffer_store(buf, n);
> early_console->write(early_console, buf, n);
> cpu_unlock(old);
>
> return n;
> }
>
> (yes, yes, we can get rid of the on-stack @buf thing with a
> reserve+commit API, but who cares :-))
Another approach is something like:
DEFINE_PER_CPU(int, printk_nest);
DEFINE_PER_CPU(char, printk_line[4][256]);
int vprintk(const char *fmt, va_list args)
{
int c, n, i;
char *buf;
preempt_disable();
i = min(3, this_cpu_inc_return(printk_nest) - 1);
buf = this_cpu_ptr(printk_line[i]);
n = vscnprintf(buf, 256, fmt, args);
c = cpu_lock();
printk_buffer_store(buf, n);
if (early_console)
early_console->write(early_console, buf, n);
cpu_unlock(c);
this_cpu_dec(printk_nest);
preempt_enable();
return n;
}
Again, simple and straight forward (and I'm sure it's been mentioned
before too).
We really should not be making this stuff harder than it needs to be
(and anybody whining about lines longer than 256 characters can just go
away, those are unreadable anyway).
Powered by blists - more mailing lists