lkml.org 
[lkml]   [2012]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] printk: Add printk_flush() to force buffered text to console
    From
    Date
    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.




    \
     
     \ /
      Last update: 2012-06-21 21:21    [W:0.028 / U:58.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site