Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I don't want the video/terminal driver in as part of my kernel(just doesn't seem right, not extensible), but I'd like to be able to output to the screen while I'm loading drivers and the like. How's this conventionally done? I noticed this in a log file:
In early boot, Linux is simply writing to the kernel ring buffer. Once the display is initialized, it's displayed.
If you really, really need kernel output before the display driver is loaded, I would recommend just writing
a very simple display driver to include in the kernel in, say, a separate executable section, page-aligned so
you can simply free that page when you're done with it.
inx wrote:I would recommend just writing a very simple display driver to include in the kernel in, say, a separate executable section, page-aligned so you can simply free that page when you're done with it.
I agree with having a simple output driver (can be output to a serial port as well), but that driver will be so small, it'll always be no more than a single 4KB page. I don't see the need to free it.
TylerAnon wrote:Thanks for your replies. I think I get what you're saying; that I should buffer output until the driver is loaded.
Yes, especially if you want to write the output to persistent media, e.g. in a log file. But if you want to display something on the screen while the OS is loading, a simple graphics driver (e.g. text mode only for x86) is the way to go (apart from buffering).
TylerAnon wrote:I don't want the video/terminal driver in as part of my kernel(just doesn't seem right, not extensible), but I'd like to be able to output to the screen while I'm loading drivers and the like. How's this conventionally done?
With careful design, it's possible to start "boot modules" (that use the firmware to setup a video mode and output the contents of the Boot Log to screen, or handle serial ports to output the contents of the Boot Log to a dumb terminal, or whatever else) during boot, well before the kernel is started; and for these "boot modules" to end up looking like normal processes after the kernel is initialised (and they could even switch from direct hardware access to using the appropriate driver when drivers are started).
Before the boot module/s are running I use the firmware to display the Boot Log (e.g. "int 0x10, ah=0x0E"); and make the PC speaker beep if a serious error occurs (in case it's a headless system with no video).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
I'd been considering a design much like that; loading drivers as grub boot modules. But I came to the problem of how to transition those modules to processes after multitasking had been initialized. And how to connect all the things a normal process has like stdio. After multitasking, does the kernel itself need to be a normal process, or can it be it's own type of task?
I think I might go the initrd-like way. I'll have a simple file system that could be read be the kernel to find a simple port io hdd driver, a few file system drivers, and a terminal driver. Everything else could be stored on the disk and loaded when needed.
