Re: console server and kernel prints

[Roland McGrath]

> when we use a true user space console which accesses the gva graphic card at
> the hardware level (I/O ports, mapped memory), we will face some interesting
> races with the kernel.

I don't think the kernel ever ought to compete.  In Linux, even if you run
X on tty1 (vt1) I don't think the console messages overwrite the screen.
kmsg or whatnot should be fine for normal operation.

When the kernel is crashing, it is certainly desireable to see its
messages.  But in that case, I don't see a problem with the kernel
resetting the video hardware and discarding its prior state to print the
panic messages.

> Why doesn't every PC have a serial console for kernel messages built in?

They do.  You just have to use it.

[Niels:]
> For serious debugging of kernel panics, you'd want to use a gdb on the
> serial line, or a real crash dump for post-mortem debugging (I'm not
> very familiar with crash dump feature, but I think it means writing
> the system state onto the swap partition, or some other partition
> reserved for this very purpose).

Indeed so.  Theoretically there should not be so common a need for this in
a microkernel system, which might be the reason Mach never had it
implemented.  What Unix systems do is dump all the memory to the high part
of the swap space, and write some magic numbers and checksums there so that
on rebooting a program can examine the swap see that it hasn't been
overwritten, and extract the dump.  The kernel cannot do this generically
in Mach right now, because it doesn't know anything about the swap
partitions (it's in the hands of the default pager, a user task).  However,
it should not be very hard to implement something for dumping to a disk
partition if it is explicitly configured (e.g. dump=hd0s4 in the kernel
command line).  I have no particular motivation to work on such a feature
though, since if the kernel crashes I would like to see it debugged with
remote gdb and fixed.