lkml.org 
[lkml]   [2018]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 1/3] printk: Add line-buffered printk() API.
From
Date
On 2018/11/08 20:24, Petr Mladek wrote:
>> Let's have one more look at what we will fix and what we will break.
>>
>> 'cont' has premature flushes.
>>
>> Why is it good.
>> It preserves the correct order of events.
>>
>> pr_cont("calling foo->init()....");
>> foo->init()
>> printk("Can't allocate buffer\n"); // premature flush
>> pr_cont("...blah\h");
>>
>> Will end up in the logbuf as:
>> [12345.123] calling foo->init()....
>> [12345.124] Can't allocate buffer
>> [12345.125] ...blah
>>
>> Where buffered printk will endup as:
>> [12345.123] Can't allocate buffer
>> [12345.124] calling foo->init().......blah
>
> We will always have this problem with API using explicit buffers.
> What do you suggest instead, please?
>
> I am afraid that we are running in cycles. The other serious
> alternative was having per-process and per-context buffers
> but it was rejected several times.

Is it possible to identify all locations which should use their own
printk() buffers (e.g. interrupt handlers, oops handlers) ? If yes,
automatically switching printk() buffers (like memalloc_nofs_save()/
memalloc_nofs_restore()) will be easiest and least error prone.

\
 
 \ /
  Last update: 2018-11-08 12:48    [W:0.210 / U:1.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site