On 2019-03-06, Petr Mladek <pmladek@xxxxxxxx> wrote: >> _Both_ categories are important for the user, but their requirements >> are different: >> >> informational: non-disturbing >> emergency: reliable > > Isn't this already handled by the console_level? > > The informational messages can be reliably read via syslog, /dev/kmsg. > They are related to the normal works when the system works well. > > The emergency messages (errors, warnings) are printed in emergency > situations. They are printed as reliably as possible to the console > because the userspace might not be reliable enough. I've never viewed console_level this way. _If_ console_level really is supposed to define the emergency/informational boundary, all informational messages are supposed to be handled by userspace, and console printing's main objective is reliability... then I would change my proposal such that: - if a console supports write_atomic(), _all_ console printing for that console would use write_atomic() - only consoles without write_atomic() will be printing via the printk-kthread(s) IMO, for consoles with write_atomic(), this would increase reliability over the current mainline implementation. It would also simplify write_atomic() implementations because they would no longer need to synchronize against write(). For those consoles that cannot implement write_atomic() (vt and netconsole come to mind), or as a transition period until remaining console drivers have implemented write_atomic(), these would use the "fallback" of printing fully preemptively in their own kthread using write(). Does this better align with the concept of the console_loglevel and the purpose of console printing? John Ogness
