lkml.org 
[lkml]   [2019]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: printk meeting at LPC
Date
On 2019-09-18, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
>> Each console has its own iterator. This iterators will need to
>> advance, regardless if the message was printed via write() or
>> write_atomic().
>
> Great.
>
> ->atomic_write() path will make sure that kthread is parked or will
> those compete for uart port?

A cpu-lock (probably per-console) will be used to synchronize the
two. Unlike my RFCv1, we want to keep the cpu-lock out of the console
drivers and we want it to be less aggressive (using trylock's instead of
spinning). This should make the cpu-lock less "dangerous". I talked with
PeterZ, Thomas, and PetrM about how this can be implemented, but there
may still be some corner cases.

I would like to put everything together now so that we can run and test
if the decisions made in that meeting hold up for all the cases. I think
it will be easier to identify/add the missing pieces, once we have it
coded.

John Ogness

\
 
 \ /
  Last update: 2019-09-18 11:05    [W:0.303 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site