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.
