Re: [PATCH] printk: Add printk_flush() to force buffered text toconsole

From: Steven Rostedt
Date: Thu Jun 21 2012 - 14:29:38 EST


On Thu, 2012-06-21 at 11:17 -0700, Joe Perches wrote:
> 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.

Are you using a 50 char width terminal?

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

A global buffering disable may cause other things that are printed to be
screwed up. Something that actually expects to be buffered. Which is why
I'm leaning to the log level version. As it keeps it contained to the
actual printk that does not want buffering.

Or perhaps have printk_flush() become a new printk. That is,
printk_flush("this does not buffer").

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/