On 2019-09-18, Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> wrote: >>>> 2. A kernel thread will be created for each registered console, >>>> each responsible for being the sole printers to their respective >>>> consoles. With this, console printing is _fully_ decoupled from >>>> printk() callers. >>> >>> sysrq over serial? >>> >>> offloading this to kthread may be unreliable. >> >> But we also talked about an "emergency flush" which will not wait for >> the kthreads to finish and just output everything it can find in the >> printk buffers (expecting that the consoles have an "emergency" >> handler. We can add a sysrq to do an emergency flush.
The problem with only a flush here is that the sysrq output may not fit in the ringbuffer (ftrace, for example). It probably makes more sense to have a switch to enter/exit "synchronous state", where all atomic consoles are flushed upon enter and all future printk's are synchronous on atomic consoles until exit. I expect sysrq to be the only valid use of "synchronous state" other than oops/panic. Although I suppose PeterZ would like a boot argument to always run the consoles in this state. > I agree that when consoles have ->atomic_write then it surely makes > sense to switch to emergency mode. I like the emergency state > approach, but I'm not sure how it can be completely invisible to the > rest of the system. Quoting John: > > : Unlike oops_in_progress, this state will not be visible to > : anything outside of the printk infrastructure. > > For instance, tty/sysrq must be able to switch printk emergency > on/off. The switch/flush _will_ be visible. But not the state. So, for example, it won't be possible for some random driver to determine if we are in an emergency state. (Well, I don't know if oops_in_progress will really disappear. But at least the printk/console stuff will no longer rely on it.) > We also figured out that some PM (hibernation/suspend/etc.) stages > (very early and/or very late ones) [2] also should have printk in > emergency mode, plus some other parts of the kernel [3]. > > [1] > https://lore.kernel.org/lkml/20170815025625.1977-4-sergey.senozhat...@gmail.com/ > [2] > https://lore.kernel.org/lkml/20170815025625.1977-7-sergey.senozhat...@gmail.com/ > [3] > https://lore.kernel.org/lkml/20170815025625.1977-8-sergey.senozhat...@gmail.com/ Thanks for bringing up that RFC thread again. I haven't looked at it in over a year. I will go through it again to see if there is anything I've overlooked. Particularly the suspend stuff. John Ogness
