OSDev.org

Hi,

I'm working on my bootloader and have had an idea for it: boot programs.

The current idea is that the bootloader loads a configuration file which contains the names of all the kernels on the disc. Then the user chooses which kernel to load. Some kernels can have 'boot programs' associated with them. The bootloader then loads the kernel to the point that it wants. Then if no 'boot program' is associated with that kernel it jumps straight to it. However if there is one the following happens:

1) It sets up a set of system calls for loading files from the disc and for other things.

2) It sets up a new stack and pushes the return segment and return address onto the stack

3) It jumps to the address the boot program is loaded to

4) The boot program does what it is designed to do.

5) If data structure is to be returned i.e. the boot program makes a memory map or does something else. The address is put in the eax register.

6) The boot program jumps back to the location specified on the stack.

7) The bootloader jumps to the kernel with the address still in eax.

Do you think this is a good idea or is it a bit of overkill for a bootloader? Would you change anything or edit it. I'm also adding support for standalone 16 bit realmode programs that could be loaded by the bootloader as well.

I'm releasing the bootloader once this is added so do you think this is a feature that would be used or one that would go by the wayside?

If you want to put this inside 1 sector, you will first have to use every instruction wise, since it should be impossible, or close to ( it is only 512 bytes, unless you are using CD ... ).
second, how would you know what the user have chosen, a configure file ?
last: what if the desired kernel are damaged, and what is the kernel overwrites the stack, due to DMA or similarly.
sugestion: instead of using the stack, just reload the 0 sector, and be sure about the drive, and then jump at the beginning. ( remember pmode and such things )

KMT dk

Sorry I forgot to say that it is a 2 stage bootloader. So the first stage loads a much larger second stage.

The second stage searches for the file JCONFIG.INF and if this file is not found it shows an error message. This file has to always be present.

Thats a good idea for the last point so I'll try and implement it

Why would I use your solution? What are the advantages? Why have boot programs? Why not do it with the kernel?

My boot sector loads a 16 bit loader. It loads my kernel and transfers control to it.

Im going to have to ditto Dr. Evils question.

What I though you were going to suggest was what Im implementing in my bootloader. Due to odditys in the Polkovnik kernel programs have to be initialized on it. Thusly it requires boot programs to be set up but the bootloader jumps to the kernel and the kernel handles them. I dont really see the use of a program before the kernel. Bootloader should have taken care of everything that there is to do outside of the kernel.

I guess it could possibly come in handy if lets say I was to use your bootloader with polkovnik and I needed the init of the root kernel to be done between boot and kernel. However for most I dont see a use.

The idea was that the kernel might not want some things that the bootloader provides or wants things that the bootloader doesn't provide. Perhaps it wants the video mode changed at start up. Perhaps it for aesthetic purposes wants a fancy logo or something else displayed. It means that when the kernel is jumped too it is in protected mode and so it doesn't have to worry about switching back to real mode to do something that the bootloader doesn't do as standard. The advantage is that the bootloader can be customised to provide all the information about the system that the kernel wants rather than the kernel having to switch to real mode or switch to virtual 8086 mode later on.