OSDev.org

I've been doing a bit of OsDev, and I want to start with user mode and so on. I feel that getting the memory layout straight would be really important going forward. Here is what I've planned: All addresses are virtual, I have a working page frame allocator and virtual memory manager. I am looking for ways to implement a kernel heap.

Address Range --- Use
0x0 - 0xC000000 --- User pages, and I want the user mode stack to start at 0xC000000 and grow downwards
0xC000000 - __end --- __end is something I get from the linker script which lets me know the size of the kernel
__end - __end + 0x30000 --- VGA
__end +0x30000 - ??? --- A kernel heap/ dynamically allocated memory
??? - 0xFFC00000 --- The kernel stack, grows downwards
0xFFC00000 - 0xFFFFFFFF --- Recursive page technique -> Page tables/Page directory

Also, each process has a kernel stack and a user stack... whenever I context switch I can remap the virtual addresses corresponding to the stacks to the corresponding page frames. The page frame addresses (physical addresses) will be part of the context of the process.

Is this strategy a good idea??

I've read about implementations which have a different stack pointer virtual address per process(At least MIT's xv6 seems that way). I am confused as to how this actually works

This strategy might would work, but would be complicated. What I do is put 4096 KB user stacks above the process's executable image, and allocate a kernel stack on the heap for every process. When context switching, just switch address spaces (as each user process should have its own address space), and load the new process's user stack into esp, and its kernel stack into the TSS. A good TSS tutorial is here, and info about address spaces can be found here and here. This a very tricky part of OS Dev, but is very important to get right. You can also find the source to my OS and see how I did it here. Hopefully this helps and was understandable.

So a user stack would come after .bss section perhaps?
(In the userspace) How would I expand this, especially if it's only 4K virtual address size? Or I just wouldn't (stack smashing??)

MIT's xv6 does it in the same fashion as you have suggested, and I don't want to overcomplicate my kernel. I'll just have to implement my heap well then. Any good resources? I have a decent page frame allocator.

Also where does one store the VIRTUAL ADDRESS of the current page directory? Recursive pages technique is excellent for me, and I'm wondering how you'd do it...

Yes, it would come after the .bss section. As for expanding the stack, I haven't implemented this yet. You could make it 8 KB if you wanted. I know of too many resources that deal with this, I just came to this conclusion after 1 month of debugging. This method I think is probably the simplest approach to stacks.

I keep my page directories in low memory. I plan on looking into recursive paging, as keeping them in low memory is probably a risk. A good heap tutorial is here. It does contain a few bugs, however. I just created my own heap implementation, which is here. Feel free to use it if you want.

I've been reading your heap implementation here: https://github.com/NexSuite/NexNix/blob ... mgr/heap.c.

Looks like you can reduce the code size quite a bit. Also, there are things like HEAP_MAX that just don't make sense to me... Where is it used?

My heap code is a mess right now, I plan on fixing it very soon. Here is a quick rundown of the heap code

At the base address 0xC0400000, there is an array of headers. Each header is basically a pointer to the data. It contains a base address, a size, whether or not it is a hole, whether or not it is usable, and a magic number (which must be 0xDEADBEEF). The header array cannot go past address 0xC0450000. After this array, there is the heap data. It cannot go past 0xC0800000 (HEAP_MAX should be defined as that, I am going to change it. That is basic idea to the heap. Hopefully this clears things up.

If you're gonna have only one kernel heap, it'd be simpler to not use kmalloc to allocate space for the kernel heap. Just initiate it at compile time.
Also, I think using linker script symbols for HEAP_BASE, etc. would be a better idea?