On Tue, Mar 04, 2025 at 01:26:42PM -0800, Jason Thorpe wrote: > The firmware selects which CPU module gets to boot the system (the > criteria used is unimportant here), and the UART on that module is > connected to the console port and the RTC on that module is the > authoritative RTC for the system. > > Obviously, this is a lot more problematic for the console device. We > currently have no restrictions in the kernel overall around which CPU > gets to access the console device for printing messages, and don’t > even get me started on how weird this all gets with DDB.
My first thought over morning coffe was to add a thin layer on the cnputc/cngetc/cnpollc interface level. Basically have a stack of cn_tabs (only the necessary parts perhaps). On the Laser/TurboLaser machines have "virtual" cnputc/cngetc/cnpollc that, on the boot CPU, calls the "real" cnputc/cngetc that frobs the hardware and, on the other CPUs, xcalls to the boot CPU. I presume you can easily identify the boot CPU. I don't see a way around the xcall. The "thin layer" may come in handy when we want to deal with multiple devices acting as console like e.g. Linux has it. There you can have console on e.g. frame buffer and serial simultaneously. I'm surprised you expect weirdness with DDB. I thought DDB runs on the boot CPU and pauses all other CPUs. Doing xcalls to the other CPUs for stack traces etc. I.e. it's a non-issue for DDB. I did a bit of nxr'ing on cnputc and on subr_prf.c but that quickly turned into a maze of twisty little passages to large for my short term memory. The main thing I remember is that kprintf ends up cnputc'ing every single character. Sending a bunch of characters in an xcall might be less overhead. You are looking for an excuse to pull out the rototiller, aren't you? :-) --chris
