[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Jari-developers] basic paging, new approach [done]
From: |
asgard |
Subject: |
[Jari-developers] basic paging, new approach [done] |
Date: |
Mon, 22 Jan 2007 12:12:00 +0300 |
I'll write documentation about basic paging, kernel mapping and physical
memory allocation after allocators research will be ended.
But now, I'll try to describe changes shortly:
1) new page directory abstraction
now, exists 3 common page directory types:
pd_level0,
pd_level1,
pd_level2.
no one architecture doesn't use 4-level paging or more, so 3-level
paging is quite enough.
for example on x86 without PAE feature it'll be only two page
directories levels: level0 and level1.
where
(without PSE):
pd_level0 - global page directory
pd_level1 - page table, which holds 4K pages
(with PSE):
pd_level0 - global page directory, which holds 4M pages
pd_level1 - null
and with PAE:
(without PSE)
pd_level0 - pdpt
pd_level1 - global page directory
pd_level2 - page table, which holds 4K pages
(with PSE)
pd_level0 - pdpt
pd_level1 - global page directory, which holds 2M pages.
basic paging:
on early boot stage, I don't want to know about if cpu support PAE or
not. I just map first 4M(i thing for first time it will be enough for
quite small jari kernel) with 4K or 4M(if cpu can PSE) pages.
NOTE: all data structures for pages holding are created dynamically.
Allocation starts near after kernel code ends. So, all pages hold in
safe place =).
After it, i just jump to identity mapped 3G(0xC000...) address. After it
I want to map first 1G of kernel space. But I want to use for this goal
physical memory allocator(or may be boot memory allocator if my research
will be failed =() to control* as much allocated memory as possible.
*control means replacing pages, swapping, etc, freeing, reallocation,
etc.
good luck.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Jari-developers] basic paging, new approach [done],
asgard <=