OSDev.org

Hi.
I think I have now pretty good understanding on how paging works (including reverse directory mapping ).
I'm now designing how the mapping algorithm should be.
I've got several questions I'm trying to answer before I start implementing.

1. Is there any guidelines to the mapping page function ?
Should consecutive calls to the mapping page function result in linear address mapping ? (next call to function will map: last mapping + PAGE_SIZE).

Is there any logic to not doing so ?

2. Is there any requirement to give API for mapping into a specific virtual address ?

Will glad to hear your thoughts regarding this.

Thanks !
Ramon.

Hello,
You should keep those two kind of function in separate methods:
* The function that gives you a "free virtual memory slice". Actually, you'll want many functions that give a memory slice, because you'll want to allocate kernel heap, thread stacks, and maybe shared memory between CPU cores.
* The function that maps a free memory slice to a physical memory location

to answer to your question, you'll want other things than contiguous memory, because you'll have to deal with page freeing. When calling kfree multiple time, your dynamic memory management should notice that you emptied the last occupied bit of a virtual page, and should free it. That way, you'll end up with virtual memory holes in your heap.


I personally use two self-balancing-trees ( see https://en.wikipedia.org/wiki/AVL_tree ): one that keep track of free virtual area sizes (in order to quickly allocate a number of contiguous memory pages), and one that keep track of virtual area starting point (in order to quickly merge free virtual memory areas when i free a busy one)

Hi,

mellowcandle wrote:1. Is there any guidelines to the mapping page function ?
Should consecutive calls to the mapping page function result in linear address mapping ? (next call to function will map: last mapping + PAGE_SIZE).

Is there any logic to not doing so ?

2. Is there any requirement to give API for mapping into a specific virtual address ?

Will glad to hear your thoughts regarding this.

For mine; kernel's virtual memory manager keeps track of the "user-space visible type" of each virtual page (whether user-space thinks the page is not present, readable, writable, executable, etc) and the "actual type" of each virtual page (if it's not allocated yet, in RAM, in swap space, etc). It gives user-space a function to change the "user-space visible type" of an area from whatever it was to anything else (e.g. from "not present" to "read/write RAM", or from "read only RAM" to "not present", or...), which looks roughly like "changeAreaType(void *startingPage, void *endingPage, int newType);".

The kernel's virtual memory manager only checks if the area being changed is user-space (and not kernel-space); and it never determines the virtual addresses itself. Mostly; the kernel is not some baby sitter that forces unnecessary restrictions onto processes for no reason; and user-space (processes) are free to do whatever they want with their virtual address space in whatever way they want


Cheers,

Brendan