On Wed 2018-10-17 16:00:44, Peter Zijlstra wrote: > On Wed, Oct 17, 2018 at 12:50:15PM +0200, Petr Mladek wrote: > > Also note that by deferred printk I mean deferring the console > > handling! IMHO, there are _no more problems_ with storing > > the messages into the buffer if we accept that the current > > very limited use of printk_safe per-cpu buffers is easier > > than any complicated generic lockless buffer. > > They hide messages. The whole two radically different printk paths is > also quite horrible. I agree that having everything in one buffer with unified and safe access from any context would be a great win. > And lockless buffers aren't all _that_ complicated, esp. not when > performance isn't the top priority. > > And earlycon is mostly usable, esp. the serial ones. Those, when > configured, should synchronously print along. The current design > also makes that difficult. > > A wee little like so; typed in a hurry, never been near a compiler. Thanks a lot for the code. I still need to find time to better understand it. Anyway, it looks worth considering. Best Regards, Petr
