[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1340302623.22065.9.camel@joe2Laptop>
Date: Thu, 21 Jun 2012 11:17:03 -0700
From: Joe Perches <joe@...ches.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>,
Fengguang Wu <fengguang.wu@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"kay.sievers" <kay.sievers@...y.org>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] printk: Add printk_flush() to force buffered text to
console
On Thu, 2012-06-21 at 13:41 -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 10:13 -0700, Greg Kroah-Hartman wrote:
>
> > > So mind re-sending the latest version of your printk flushing
> > > fix? I'll apply it for v3.5-rc if other trees won't pick it up.
> >
> > I'll be glad to pick it up, just make it work properly :)
>
> I'm playing around with making a KERN_FLUSH "<f>". Think that's a better
> approach?
I don't think that's better. I think it's worse
because it intermixes the idea of a kernel message
logging level with a specific functionality to
emit any fragmentary message immediately.
I think a global setting via a some functions like:
(printk private variable)
bool printk_buffered = true;
bool printk_set_buffering(bool enable)
{
bool old_state = printk_buffered;
printk_buffered = enable;
return old_state;
}
and maybe:
bool printk_get_buffering(void)
{
return printk_buffered;
}
would be better because the non-buffered use should
really be pretty isolated to last_breath type output
and to pretty isolated cases like your long running
tests.
A separate printk_flush() function if really necessary
but sprinking a bunch of printk_flush() calls seems
wasteful.
--
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