from the they-wouldn't-printk-it-if-it-wasn't-true dept.
Linux Sees A New Attempt At Threaded Console Printing:
As part of the multi-year effort to overhaul the Linux kernel's printk() code there has been much work in recent months around threaded console printing so each registered console would have a kernel thread and console printing would be decoupled from the printk() callers. That work was aimed for Linux 5.19 but then reverted due to troubles. There is now a new implementation in the works.
That work was reverted during the Linux 5.19 release candidate phase due to missing synchronization between early and regular console functionality and showed other possible problems in the design. Due to printk() being critical for Linux kernel debugging and being a fundamentally important feature, the code was reverted.
Thomas Gleixner with Intel-owned Linutronix has posted a set of 29 patches this weekend under a "request for comments" flag featuring a redesign of the printk() code around the per-console threading.
After working it out with John Ogness who worked on the prior code, these Linutronix engineers hope the new code is in much better shape and more robust.
(Score: 3, Insightful) by coolgopher on Tuesday September 13 2022, @01:01PM (5 children)
If this implies that the boot is no longer held back by printing to a 115200 serial console, then I'm looking forward to this.
(Score: 3, Interesting) by bart9h on Tuesday September 13 2022, @03:30PM (2 children)
the kind of mindset that led to the systemd monstrosity.
(Score: 2) by DannyB on Tuesday September 13 2022, @04:31PM
There must be some way that kernel printing could be made to be a part of systemd.
How often should I have my memory checked? I used to know but...
(Score: 2) by coolgopher on Wednesday September 14 2022, @01:52AM
No, that was desktop driven nonsense. I'm talking about embedded devices. And I assure you, systemd gets nowhere near those!
(Score: 0) by Anonymous Coward on Tuesday September 13 2022, @06:22PM (1 child)
Not sure what Linux is doing here. Most of my BSD boot time is the wait it has coded in that gives me boot options, and it doesn't bother me enough to find the setting that gets rid of that. You've got source. If, for some strange reason, console output causes boots to be slow, there should be some way to recompile the kernel with all that commented out, or the option of only enabling it if you have a certain key pressed during boot, etc.
(Score: 2) by coolgopher on Wednesday September 14 2022, @01:50AM
"quiet" in the command line args to the kernel suppresses most of it. IPL/SPL/TPL output can be more challenging to suppress (especially with vendor binaries). It would be nice to be able to get the proper boot messages for diagnostics reasons if it wasn't holding the boot up. The systems I work with (embedded / "IoT") don't wait for human input for anything, they're completely standalone. But if I there's a way to have my cake and eat it as well (i.e. full diag messages and fast boot times) I'll happily take it!