The general design I have chosen for the kernel is what is called a "Higher-half Kernel". This is where the kernel occupies the uppermost portion of the memory space for each process. This is good because the kernel is always at the same place in memory and programs can all be linked as if they were at the 0 memory mark, but it does mean the process and kernel memory have to share the memory space which, on a 32-bit machine, means dividing up only (only!) 4GB.
The kernel will be linked as if it always lives at the 3GB (virtual) mark, but the multiboot loader will load it at the 1MB (physical) mark. The first thing my kernel has to then do is partially configure the virtual memory before the kernel code can perform any jumps or reference any global symbols, or generally run any part of the C kernel. The easiest way to do this is to create a small assembly file which will contain the multiboot entry point which will do this configuration. Assembly is a good choice because I can write it as if it was linked at 1MB where needed, and the linker won't mess with that.
The initial virtual memory configuration will be that the first 4MB of physical memory is mapped to the 3GB mark for kernel memory. This is a good thing because the first 4MB contains some interesting things; BIOS areas, 16-bit DMA memory, and the kernel itself. Also, the multiboot header data is quite likely to be in here, but if it isn't, we need to rescue it before it gets overwritten. This 4MB allocation is also really useful because it gives us a little bit of available memory that we can use before we need to worry about getting more frames allocated. (I will also, for the moment, map the first 4MB physical to the first 4MB virtual as well, but I don't intend for this to be the case long term.)
There are things we need to consider that are scattered throughout physical memory that we need to be aware of, such as; the multiboot header and its various tables, the ACPI tables, the E820 memory map result (although this is probably in the multiboot header data), etc. We have something of a problem because we need to know what memory we can use for our kernel before we can actually find where these things are and then see if we've already overwritten anything important. There isn't a way to do this unfortunately, other than to use a block of memory that is least likely to be used by other things yet. Many OSes assume the 1MB mark (as I have done) which seems to be the safest, and as you increase the memory address, the probability of hitting something increases. However, I have seen the 1MB mark used when using a network boot ROM in the past, if this becomes a problem, I may have to revisit it.
If we have less then 4MB of physical memory in the machine, we're going to have a bad time, so for now we'll just say that 5MB is the minimum physical memory for the OS. This gives us the 4MB of memory for the kernel, and 256 pages of memory to be allocated where needed. I could make the initial allocation for the kernel smaller to support a smaller physical memory requirement, but that's unnecessary for moment. The reason for choosing 4MB as the initial kernel allocation is so that I can use a single page table to cover this (each of the 1024 page tables covers 4MB, making a 4GB memory space, in the 32-bit world).
Next thing we need to worry about is actually allocating physical memory. The easiest way to track this is to set a pointer to the top of the 4MB physical that we have used already. When we need to allocate a new page, we use the page at this pointer then inclement the pointer by one page. It means for now that we can't reallocate pages or track their usage, but we have more physical memory that we need right now. A kernel panic when we have run out of available physical memory will suffice for now.
My intention is eventually to create a physical memory map that mirrors the virtual memory map used by the i386 architecture, and use it to keep track of what goes where. It can use a single page to store the top level data as 1024 32-bit entries, each of which either tracks a 4MB block of physical memory, or contains the address of a page which further breaks the 4MB down into 4KB pages. Each entry, be it referring to a 4MB page or a 4KB page, tracks the time since this page was last accessed, and whether it is dirty (changed since it was last copied into the pagefile). Incidentally, the reason that Windows seems to be constantly accessing your hard drive is because it is copying pages of memory that have changed (been written to by a process) from memory to the page file, just in case a process suddenly needs lots of memory.
