On 2018/09/29 20:13, Sergey Senozhatsky wrote:
> On (09/28/18 20:21), Tetsuo Handa wrote:
>> 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?
>
> Could be. If this is the last thing you are about to see on your
> serial console. panic_on_flush() is not guaranteed to succeed.
Doing
printk("going to call early_init_foo()...\n");
early_init_foo();
printk("OK\n");
and getting
T0: going to call early_init_foo()...
as the last line we see on our serial console will not be so bad.
Implicitly flushing incomplete lines might disturb automated processing.
But there is after all other factors which can disturb automated
processing (e.g. "** %u printk messages dropped **\n" in printk(),
UDP packet being lost when transmitting via netconsole). After all,
we cannot allow perfect automated processing. The last help is
human's eyes and brain.
Then, prefixing caller information helps even if incomplete line
is implicitly flushed by line buffered printk() API...
