lkml.org 
[lkml]   [2017]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: printk: what is going on with additional newlines?
    On Tue, Aug 29, 2017 at 1:41 PM, Tetsuo Handa
    <penguin-kernel@i-love.sakura.ne.jp> wrote:
    >>
    >> A private buffer has none of those issues.
    >
    > Yes, I posted "[PATCH] printk: Add best-effort printk() buffering." at
    > http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp .

    No, this is exactly what I *don't* want, because it takes over printk() itself.

    And that's problematic, because nesting happens for various reasons.

    For example, you try to handle that nesting with printk_context(), and
    nothing when an interrupt happens.

    But that is fundamentally broken.

    Just to give an example: what if an interrupt happens, it does this
    buffering thing, then it gets interrupted by *another* interrupt, and
    now the printk from that other interrupt gets incorrectly nested
    together with the first one, because your "printk_context()" gives
    them the same context?

    And it really doesn't have to even be interrupts. Look at what happens
    if you take a page fault in kernel space. Same exact deal. Both are
    sleeping contexts.

    So I really think that the only thing that knows what the "context" is
    is the person who does the printing. So if you want to create a
    printing buffer, it should be explicit. You allocate the buffer ahead
    of time (perhaps on the stack, possibly using actual allocations), and
    you use that explicit context.

    Yes, it means that you don't do "printk()". You do an actual
    "buf_print()" or similar.

    Linus

    \
     
     \ /
      Last update: 2017-08-29 22:51    [W:2.826 / U:0.460 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site