lkml.org 
[lkml]   [2017]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread
From
Date
Sergey Senozhatsky wrote:
> On (06/30/17 19:18), Tetsuo Handa wrote:
> > > I'm still thinking about Steven's proposals; but we will need offloading
> > > anyways, so the bits we are talking about here are important regardless
> > > the direction printk design will take, I think.
> >
> > Is there a chance that printk() waits for only data queued by that printk()
> > call (exception will be printk() from NMI).
>
> hm, I don't think this can be done easily... consider
>
> console_lock();
> printk();
> printk();
> ... -> this guys will wait forever. nothing
> flushes the logbuf.
> printk();
> console_unlock();

Can't we remove console_lock()/console_unlock() from printk() ?
I think that printk() depends on console_unlock() is complicating.

\
 
 \ /
  Last update: 2017-06-30 23:13    [W:0.062 / U:1.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site