OSDev.org

I've read about paging for days and days, and I am still stuck with a couple of questions.

Would this make for a good Physical and Virtual Allocator w/ paging?

My kernel has a PD with everything marked Phys->Virt (1:1).
When I load a new application (or thread not part of the kernel), I create a new PD bringing in the kernel to like 0mb virtual (protected), and app to be loaded at 1mb then the app will be give its size + 4k in allocated pages. The rest of the pages in the PD would be Not-Present. When the app requests more, the kernel allocs pages (if neccessary) and maps the pages into the apps virtual space for malloc to chop up.

Does that seem anywhere near right?

Thanks,
Rich

omg why is no one responding...

lol j/k (I saw someone say that awhile back and thought it was funny till I saw they were serious)...

Anyway to further detail the above, I was think if the kernel has itself and all of its structures below 4mb (in the first pt) and that is mapped into an apps pd, then when the app calls a kernel function or an interrupt fires, there wouldn't need to be a pd switch, until the scheduler said it time for a new app to run, at which the pd could be swapped out, and being that in every case 0-4mb is always 0-4mb it shouldn't disrupt anything, and should be just a clean switch.

It seems to make sense to me... unless I am wrong on a concept.

Thanks,
Rich

you could just edit your first post, you know

anyways, most memory managers just map the kernel into every PD, and as you say, that eliminates the need to switch context every time you get an interrupt

you might want to relocate your kernel to a higher address though
most virtual memory layouts keep the high 1GB (0xC0000000 to 0xFFFFFFFF) for the kernel and leave the lower 3GB to userspace processes
this is not necessary, but its pretty much a standard by now, and it does make things easier (4 mb is really too small for anything but a very simple kernel and most userspace apps are linked to low addresses by default)