Hi,
Aerath wrote:
If I understood recursive mapping, it has a fixed layout. I mean, given a virtual address, it will always have the same physical translation (and that's why one can use formulas to translate physical to virtual). But I want to be free to map any virtual address anywhere in the physical space.
I'm not sure if this matters (if it's an irrelevant typo or a fundamental misunderstanding of how paging works), but you can't map a virtual page into the physical address space - you can only map physical pages into (one or more) virtual address spaces.
An OS developer is free to do whatever they like with virtual address spaces; however typically they start by splitting it into "fixed layout" areas. For example:
Code:
0x00000000 to 0xBFFFFFFFF = user-space
0xC0000000 to end of kernel's .bss = used by kernel's executable
End of kernel's .bss to 0xFFBFFFFF = used by kernel's dynamic memory management ("heap" or whatever)
0xFFC00000 to 0xFFFFFFFF = used by recursive mapping
Aerath wrote:
Besides, Brendan, you said
Quote:
finding the virtual address of a page table is very fast (e.g. for plain 32-bit paging, maybe "pointer_to_page_directory_entry = (virtual_address >> 20) & 0xFFFFFFFC + 0xFFFFF000" and "pointer_to_page_table_entry = (virtual_address >> 10) & 0xFFFFFFFC + 0xFFC00000").
I guess by
pointer_to_page_directory_entry you mean the virtual address, since finding it is what I am looking for and what you are talking about in your previous sentence.
However your formulas use
virtual_address as an input. It seems strange to me, since it's the result we are looking for. Or maybe I guessed wrong.
The typical scenario is that you have a virtual address of something (e.g. of an area where "sbrk()" wanted the kernel to allocate more pages, the virtual address that caused a page fault, the virtual address that an executable loader wanted to memory map part of an executable file, etc), and need to find the virtual address of the page directory/table entries that correspond to that original virtual address.
Cheers,
Brendan