On (03/06/19 23:22), John Ogness wrote: > 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: OK, you guys are ahead of me. FB folks want to have a per-console sysfs knob to dynamically adjust loglevel on each console. The use case is to temporarily set loglevel to, say, debug on fast consoles, gather some data/logs, set loglevel back to less verbose afterwards. Preserving the existing loglevel behaviour looks right to me. > - if a console supports write_atomic(), _all_ console printing for that > console would use write_atomic() Sounds right. But Big-Konsole-Lock looks suspicious. > - 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(). This sounds concerning. IMHO, netconsole is too important to rely on preemptible printk and scheduler. Especially those netcons which run in "report only when oops_in_progress" mode. Sometimes netconsole is the fastest console available, but preemptible printk may turn it into the slowest one. -ss
