lkml.org 
[lkml]   [2018]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] printk: inject caller information into the body of message
    From
    Date
    On 2018/09/28 17:56, Sergey Senozhatsky wrote:
    > The good thing about cont buffer is that we flush it on panic. E.g.
    > core/arch early boot stage can do:
    >
    > pr_cont("going to call early_init_foo()...");
    > early_init_foo();
    > pr_cont("OK\n");
    >

    Is printing

    going to call early_init_foo()...OK

    in one line so critically important? If caller information is prefixed,
    we would no longer need to support KERN_CONT. That is, we could do

    printk("going to call early_init_foo()...\n");
    early_init_foo();
    printk("OK\n");

    and get output like below.

    T0: going to call early_init_foo()...
    T0: OK

    Even if "going to call early_init_foo()..." part became too long,

    T0: going to call
    T0: early_init_foo()...
    T0: OK

    will not be so bad.

    > should early_init_foo() panic the system we will have
    > "going to call early_init_foo()" on the serial console. This can
    > be addressed if you'd iterate printk_buffers[] in flush_on_panic().

    Yes, flush on panic() would also be possible.



    > Tetsuo, do you still want to have a fixed size array of printk buffers?

    For my intended users where printk() is used for reporting errors (e.g.
    stack backtrace, GFP_ATOMIC memory allocation failure, lockdep splat),
    being prepared for already tight stack is preferable.

    >
    > What do others think?

    Yes, I want to hear from others.

    \
     
     \ /
      Last update: 2018-09-28 13:22    [W:4.165 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site