Messages in this thread | | | Subject | Re: [PATCH] printk: inject caller information into the body of message | From | Tetsuo Handa <> | Date | Fri, 28 Sep 2018 20:21:58 +0900 |
| |
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.
| |