OSDev.org

I am following the bare bones tutorial.
In multiboot specification stated that:

The Multiboot information structure and its related substructures may be placed anywhere in memory by the boot loader (with the exception of the memory reserved for the kernel and boot modules, of course). It is the operating system's responsibility to avoid overwriting this memory until it is done using it.

How can I avoid overwriting an unknown memory location?
I mean, if I define a variable for example in main function, may it overwrite that structure or it falls under memory reserved for the kernel? And to make it more clear to myself, is the memory for the variable taken from the 16KiB stack defined in boot.s?

Hi,

When your code is first started, the only memory you can safely use is memory that the boot loader reserved for your code (e.g. your ".data" and ".bss"). This does not include the stack.

The very first thing you should do is load a valid stack. For safety this stack must be in your ".bss" section.

The next thing you'd want to do is process the memory map given to you by the boot loader - doing sanity checking, sorting it, etc (and possibly converting it into a different format). Your "processed memory map" would need to be in your ".bss" section too. For areas that the boot loader neglects to include in its memory map (e.g. multi-boot information structure and memory used by your code); you could create a "used for boot data" entry type and include the area/s in your "processed memory map". Alternatively, you can copy data from the multi-boot information structure into your ".bss" so you don't need to worry about trashing it.

After generating your "processed memory map", you'd use it to initialise some sort of physical memory manager; and once that's done you can use it to safely allocate whatever memory you need.


Cheers,

Brendan

Complementing Brendan's advice.

To avoid confusion, instead of using .bss, you can create separate .heap section with same flags. That can be easily done in linker script.

You could make it large enough (say 128 KiB), and handle it over to some implementation of malloc(). Then you can use dynamic memory allocation from very early stages of kernel initialization.

Thank you