Hi,
OSMAN wrote:I want to implement a physical memory manager. Can you tell me what functions should it offer to higher level code? (I have memcpy,memset. Do I need alloc_page?) What should it do, exactly?
For the physical memory manager (if you use paging), you'd need functions to allocate a single page and free a single page. For ISA DMA you'd also need a function to allocate contiguous pages below 16 MB that don't cross 64 KB boundaries.
If you are supporting PAE, then you'd need a seperate function to allocate a page above 4 GB (with the original version used for pages below 4 GB). This is because CR3 still needs a 32 bit address and some PCI devices can't access memory above 4 GB.
This gives the following functions:
- * allocate page below 4 GB
* allocate page above 4 GB
* allocate DMA buffer below 16 MB
* free a page
On top of this, somewhere in your OS you may need to find unused areas of the physical address space for when you're configuring PCI devices. For example, if there's a second video card you may need to find a 64 MB area for it that doesn't conflict with anything else. IMHO it's best to forget about this until you need it, but, make sure you keep a list of areas and what they are used for (for example, keep the list that "
int 0x15, EAX = 0xE820" or GRUB gives you).
OSMAN wrote:I'd like to have a good explanation of why to page. I don't believe I know about paging very much yet, even I've been reading about it a lot!
INMHO paging is harder to figure out to begin with, but much easier than segmentation once you've figured it out.
With segmentation (and without paging) every segment must use contiguous chunks of physical memory, which causes major headaches.
For example, imagine you've got a computer with a memory map like this:
0x00000000 to 0x0009FFFF - RAM (640 KB)
0x000A0000 to 0x000FFFFF - Reserved
0x00100000 to 0x00EFFFFF - RAM (14 MB)
0x00F00000 to 0x00FFFFFF - Memory hole
0x01000000 to 0x01FFFFFF - RAM (16 MB)
Now assume you've got an application that wants to use 20 MB of memory. Without paging it can't be done because no single area is large enough, even though there's almost 31 MB of usable RAM. How about five applications that want 5 MB each?
Now consider swap space. Imagine you've got a computer with 4 MB of RAM, and the user wants to start an application that has a 5 MB executable file and needs a total of 10 MB. With paging this is possible - you'd memory map the executable file so that it doesn't need to all be loaded into RAM at the same time, then you'd use "allocation on demand" for the rest, so that RAM is only allocated when it's used and not before. When you run out of RAM, any pages of the executable file that haven't been modified can be recycled and loaded from the executable file on disk if they are needed again, and the swap space would be used to store pages that have been modified.
In the same situation without paging you'll have huge problems. You can't even use the swap unless it's memory at the start or end of the segment.
There is one solution for all of the problems above that doesn't use paging. The idea is to force applications to use many small segments, so that segments can be shuffled around in memory and entire segments can be sent to swap.
The problem here is that the application would need to be written to support it - for example, you'd have code segment/s, data segment/s and a stack segment, "malloc()" would return a segment instead of an address, etc. The problem here is that it's more difficult to write an application like this (even in assembly), no compiler will support it and constantly juggling segment registers is slow due to the privilege checks the CPU does.
In addition you'd still have physical memory fragmentation problems and you'll need to relocate entire segments to solve them, and your swap space will be slow and complicated. For e.g. if there's six 1 MB segments in use and you need 20 KB, you'd have to wait while 1 MB is sent to disk (you couldn't split it). The swap space code would also have to deal with variable length chunks (and you'd have fragmentation problems here too), rather than 4 KB chunks (which is easy to do).
IMHO using segmentation alone is ugly, more complicated, less powerful and slower. It can be more secure though - for example, imagine a 20 byte segment where accidentally trying to access byte 21 gives a general protection fault (this can't be done with paging alone).
Of course it's possible to use both segmentation and paging to get the benefits of both. This can be used to create an extremely secure OS, but normally the benefits aren't worth the extra complexity (especially as compilers don't support it).
Cheers,
Brendan