>Hmm, good idea, but how does this work on, say, non-x86 architectures
>which don't have a VGA text frame buffer, or whose VGA text frame buffer
>is not mapped in, or whose VGA text frame buffer is not initialised.
>
>You will still end up with those "my kernel hangs during boot" messages.
>
>A lot of the problems with debugging early kernel hangs is that you
>don't have a display set up, or you don't have enough of the memory
>subsystem initialised (eg, before pci_init) to be able to access
>devices (eg, before paging_init).
[.../...]
I've implemented a similar mecanism on the PPC 2.2.x kernel. It's not in
the main tree since it requires a couple of lines of change to printk.c
in order to handle correctly the removal of the last console.
Basically, I setup a "struct console" during very-early boot (almost at
the firmware level) that can basically display text on screen (using the
firmware pre-inited fb) using a very basic engine, and is setup by
default as the printk console.
Then, in the main VT code, I unregister this boot console just before
registering the VT one.
It's a bit hackish and so is not meant to be merged in the main tree, but
it's useful when I release test kernels for new Apple hardware, to have
printk work from the very beginning of boot.
I wanted to clean it up, but I didn't figure out a way to make this work
without hacking slighlty printk.c and vt.c (mostly for correctly handling
the takeover of the boot console by the VT subsystem). It could have been
simpler if I implemented a struct consw instead of the (simpler) struct
console, but the resulting code would have been way too bloated (mostly
re-implementing an fb-based console ;)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:27 EST