[lkml]   [2019]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] printk: Introduce "store now but print later" prefix.
On (03/06/19 11:04), Petr Mladek wrote:
> > I'm suggesting to use a non-async printk() for $trailer_text_line line. I think
> > that changing all printk() called from out_of_memory() to async is doable, if
> > the caller of out_of_memory() wakes up a dedicated kthread described below.
> This is error prone. The trailing printk is not guaranteed:
> + It might get lost by code refactoring.
> + People would miss that it is needed when async printk is used
> in a shared function, e.g. dump_stack().
> + People will not know that it is needed because they
> are not familiar with the API. The would just use it
> as part of a cargo cult programming or so.
> For this reason, this API is a "no no no" from my side.

Conceptually, this buffering is just pr_cont() with extension
from "1 line" to "N lines". pr_cont() also waits for a special
marker to flush the buffered data - that marker is pr_cont('\n'),
which forces printk to log_store() cont buffer. In Tetsuo's
proposal the marker is different. That's the only difference I
see. Should any other CPU printk() anything - it will print out
buffered data, same thing as pr_cont(), again.


 \ /
  Last update: 2019-03-06 15:28    [W:0.171 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site