OSDev.org

I am writing memory management and I'm stuck, I want to use memory management before kernel start, that mean my memry management will be able to create two zones: Kernel memory zones, where I placed my kernel, then load my kernel (stored in binary) into memory, then execute kernel.

However, when the memory manager is booted in the bootloader Stage 2, the bootloader will only use it to create memory area for the nuclear space, and the nucleus will use the memory management process and take responsibility For all later memory operations, including memory protection and memory area for user space.

Kernel will use memory management to mark kernel memory permissions that only kernel will have full permissions (R/W/X) to kernel memory. After that, all memory access from the outside Kernel will be rejected, even bootloader.

Then kernel will use driver framework to load drivers and enable devices, then kernel will use memory management to create another memory zone, called User-space memory zones, and they are seperated with kernel memory zone. After that, kernel startup process end up and User-space will be entered.

All processes in the user mode, when calling the functions related to memory, these functions simply call the system calling commands deployed by Kernel. Kernel will then be responsible for manipulating memory, and providing that memory for that process, and because the nucleus will manipulate all operations related to memory on the user space memory area. From the time the user space is executed, there will be no security problem.

That is my idea.

But if so, we will have a chicken and egg problem. I will have to create two memory managers but it uses the same title files. This creates a lot of problems because I will have to maintain two memory managers at the same time.

However, if developing a common memory manager for the whole system, where should I put it? Moreover, after bootloader transferred the rights of nuclear management, how will the nucleus use the memory manager? It should be searched for memory management, or it is imperative to deploy a memory manager for Kernel and still use the same old title files, just because Kernel does not know how to reuse the memory manager.

The two memory management processes for bootloader and kernel, but have the same features and functions because they use the same title files that seem not to be wise decisions.

What is the best solution for this? Should I write a common and only memory manager for the whole system to be smartest?

Why? What do you want to do with it?

In a typical OS, the bootloader needs to find some available memory to load the kernel, then it needs to set up page tables to map the kernel. After that, the bootloader is done. It doesn't need the kernel's memory manager.

Agreed, but the bootloader doesn't need to setup paging either. My bootloaders (both BIOS and EFI) will enter the kernel in protected mode without paging. It's then up to the kernel to setup paging as it wishes.

Unless you're developing for 64-bit x86. That requires a page table set up before you can enter long mode. You can setup an identity map, but at that point why not just set up a higher half map in the bootloader?

But you don’t have to enter 64-bit mode in the bootloader. It’s semantics really, but not all (what are commonly known as) bootloaders put the loaded program into 64-bit mode. It can be part of the kernel’s initialization routine.

That's a crappy way to do it, but yes, some kernels do have to bring themselves up to 64-bit mode because the bootloader put them in 32-bit protected mode. It requires some unsightly hacks to combine 32- and 64- bit code into one, though.

You don’t have to combine 32- and 64-bit modes into one.

No? Well then how do you get into the kernel proper if the bootloader placed you in protected mode, aside from inserting some 32-bit code?

You load the 32-bit code as a module (for example, using GRUB as your boot loader).

If your boot loader makes the move to 64-bit mode then it has to combine 16-, 32-, and 64-bit code. It's better to keep these as separate modules.