Messages in this thread | | | From | John Ogness <> | Subject | Re: printk meeting at LPC | Date | Wed, 18 Sep 2019 11:05:28 +0200 |
| |
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
| |