[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1340631235.27036.304.camel@gandalf.stny.rr.com>
Date: Mon, 25 Jun 2012 09:33:55 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
"kay.sievers" <kay.sievers@...y.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Wu Fengguang <fengguang.wu@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Joe Perches <joe@...ches.com>,
"Paul E. McKenney" <paulmck@...ibm.com>
Subject: Re: [PATCH v2] printk: Have printk() never buffer its data
On Mon, 2012-06-25 at 09:21 -0400, Steven Rostedt wrote:
> This brings back the old way of printk() that always prints to the console
> and does not buffer the data. As printk_emit() is used by other 'facilities'
> this only affects printk(), but keeps pretty much the new behavior.
Note, this patch brings back the old printk() behavior of not buffering
the output to the console, without the need of printk_flush() or any
helper function, and it does so without a revert of the changes that Kay
has made.
Even with Kay's changes, if multiple partial lines are printed on SMP,
those would be interleaved as well, as the new method can only save one
partial line at a time. Only full lines will not flush out the buffer.
At least with my patch, if two interleaving printks were coming out at
the same time, they would each get their own line (better than the old
way).
We could probably even add a task id output if necessary, and an
external tool could easily put them back together. Only print the task
id if a partial line was preempted by another task. But that would come
after a later debate.
I'm thinking that this patch is the best of both worlds. Most of Kay's
work is still intact, and printk() still behaves as we expect it to.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists