On (09/18/19 11:05), John Ogness wrote:
> On 2019-09-18, Sergey Senozhatsky <sergey.senozhatsky.w...@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).
That's my expectation as well. cpu-lock and per-console kthread can
live just fine in printk.c file.
-ss
