> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
