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

[Steven Rostedt]

On Thu, 2012-06-21 at 11:39 -0700, Joe Perches wrote:

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

But prints that actually require buffering disabled (like the one I'm
using) does so because it may be testing something that may crash the
system. On SMP, that crash could cause garbled output. Yes, it is pre
3.5 behavior, but why have garbled output on the crash when Kay went
through all that effort to have it work.


> 
> > Something that actually expects to be buffered.
> 
> There is nothing today that _expects_ buffering or is
> guaranteed non-buffered.

I'm not saying there is. But if the new buffering system is here, then
there may be something that will _expect_ buffering to be enabled.

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

Which means we can use individual flushing.

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

Actually, I'm starting to lean back to my original patch, and stick a
pr_flush() in there. As it basically just acts like a barrier. "Make
sure the output I printed actually gets out to the console before I
continue".

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