PatSanf wrote:
I'm worried that as I keep programming the kernel will inevitably grow beyond 4MB in size, and that once it does I'll have major issues with sections of the kernel not being mapped to any virtual address because I'm only setting up a single page table. What's the best way to avoid, or address, these concerns?
I'm willing to bet (your bitmap.c link is broken) that you are statically allocating a number of structures (in your .data section and not in your .bss section). To confirm this, I would investigate the size of your object files and start with your largest file and determine where you are using space. The result of this analysis will help you determine where to focus your attention changing things from statically allocated to dynamically allocated.
So, dynamic allocation required a memory manager. In fact, there are 3 memory managers to consider:
- Your physical memory manager
- Your virtual memory manager
- Your kernel heap manager
Now that you are moving things around in virtual memory space, you should have a memory map (design) that you are working against, and in that you should have a block of virtual memory defined for your heap. Once you have that identified, it should be almost trivial to initialize this block (or a portion of this block) of virtual memory to be your heap and start allocating memory from it (say, to manage your bitmap). The trick here is to figure out how to step your way into a full initialized memory management suite (for which you might have to just "do" some things and "inform" the appropriate memory manager what has been done after the fact and before putting it in charge).
I offered in another post that you should hand-code the paging tables in order to learn and understand the structures. Now, it's time to build the functions to set this up dynamically and replace the hand-coded stuff with dynamically built stuff.
I hope this helps.