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

[Joe Perches]

On Thu, 2012-06-21 at 14:29 -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 11:17 -0700, Joe Perches wrote:
> > On Thu, 2012-06-21 at 13:41 -0400, Steven Rostedt wrote:
[]
> > > 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?

Nope.  Just an old habit.

> > 
> > 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 sprinkling a bunch of printk_flush() calls seems
> > wasteful.
> 
> A global buffering disable may cause other things that are printed to be
> screwed up.

After Kay's deferral patch (an actual improvement), lots
of output could have been changed.  Turning off buffering
would simply revert to pre 3.5 behavior.  I don't think
that's a significant issue.

> Something that actually expects to be buffered.

There is nothing today that _expects_ buffering or is
guaranteed non-buffered.

The locations that benefit from non-buffering are few
and isolated.

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

Yuck.

Then there'd be all the likely variants for
prefix [pr|dev|netdev]_<level>[_once|_ratelimited] postfix
too.


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