OSDev

Посоветуйте с переходом на страничную организацию памяти, как сделать и где можно прочитать.
Для страничной организации нужно создавать Page Directory Entry и Page Table Entry и загружать в CR3, кстати как вариант сделать начальные значения адресов одинаковыми с виртуальными.
Я недопонимаю, как создавать таблицы для каждого процесса и при переключении процессов загружать таблицу процесса в CR3

Как говорил один персонаж борды, "а вы пробовали доку почитать?"
Начиная с http://wiki.osdev.org/Memory_management и далее там по ссылкам.

Как я понял фишки две, одна позволяет разбросанным кускам памяти казаться непрерывными, а вторая это организация адресного пространства для программ и там у нас может быть выделенные страницы для программы и страницы с системными данными для программы, причём в режиме только для чтения.
Как только эта таблица создаётся для программ?

Какая-то странная у тебя последовательность разработки...

Т.к. по существу вопроса говорить можно очень много, просто отвечу на поставленные вопросы.

Основные доказавшие свою эффективность и простоту фишки - это размещение ядра в верхней части ВАП, отображение ядра во все ВАП по одним и тем же адресам, рекурсивное отображение каталога, защита страниц ядра на уровне таблиц самого высокого уровня (например, для PM32 на уровне PDE, а не PTE).

Нужно создавать таблицы страниц. В CR3 нужно загружать физический адрес каталога страниц (PM32). Тождественное отображение необходимо только для инициализационного кода. Я при старте выполняю тождественное отображение только первого мега (или даже первых 640 Кб), причем это из-за того, что я выполняю физический перенос основных секций ядра из базовой памяти, а если бы использовалось переотображение страниц, то участок тождественно отображенной памяти мог бы быть вообще "микроскопическим".

Отображаешь вновь выделенную страницу (желательно сразу обнуленную) во временный фрейм, копируешь в нее все глобальные входы ядра из текущего каталога и записываешь ссылку на себя (физический адрес этой страницы и флаги). Переключение - mov cr3,eax (eax должен содержать физический адрес каталога того процесса, на который переключаешься; если переключаешься на другой поток текущего процесса, то cr3 можно не перезагружать).

Да, конструировать непрерывные участки памяти вне зависимости от фрагментации физической памяти, управлять доступом к образовавшимся "дырам" ("ругаться", отображать или отображать и подкачивать память по требованию).

См. выше. При использовании рекурсивно отображенного каталога ты будешь иметь в каждом ВАП таблицу страниц размером 4 Мб (конечно реально отображена в ВАП может быть лишь малая часть таблицы), а в этой таблице текущий каталог размером 4 Кб (PM32). К примеру чтобы отобразить 1 страницу по адресу 400000h в user space (младшая часть ВАП), ты должен проверить (или опять-таки использовать отображение по требованию), имеется ли для данного участка ВАП соответствующая транс-страница (мой термин, в терминологии Интел "таблица страниц" - я ее называю иначе, чтобы не путать с моей 4-мегабайтной таблицей страниц; отдельная транс-страница отвечает за отображение участка размером 4 Мб, т.е. 1024 конечных страниц размером 4 Кб), т.е. соответствующий вход в каталоге должен иметь установленный бит присутствия. Если транс-страница присутствует, ты должен сразу записать в ее первый вход (а фактически в 1025-ый вход таблицы страниц) физический адрес новой страницы и флаги. Если транс-страницы нет, то сначала проинициализировать ее, а потом конечную страницу (для этого тебе понадобятся две новые страницы). Походу нужно делать валидацию страниц, если отображение инициировано страничным сбоем.

Ну и естественно первоначально нужно четко знать матчасть.

А ещё -- для чего это вообще нужно и как памятью настоящие оси управляют. Это не курсоры на экране в Дельфях рисовать, это нечто совершенно иное.

Я об этом же. Если мы начнем углубляться в управление памятью, а ТС не подтянет матчасть, то толку от этого будет мало.

Я реализовываю страничную память для своей ОС, а у меня объекты нафаршированы адресами объектов, функций и ресурсов. У меня есть бинарное ядро которое работает по своему адресу загрузки, и если его проецировать на верхние адреса, то при компиляции надо тупо ставить ORG верхние адреса, и тогда все адреса в моём ядре настроятся сами.
А что по поводу того, что мы на каждый загружаемый процесс будем создавать свою таблицу страниц, получается, что у всех процессов может быть один и тот же начальный адрес.

Легко. Мало того, его адресное пространство может быть организовано так, как ему необходимо. Например, без дырок в памяти в первом, шестнадцатом и прочих мегабайтах.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Если кратко, то да. Вообще существуют перемещаемые ядра, в которых настройка адресов может выполняться динамически загрузчиком или в собственном позиционно независимом инициализационном коде. Лично я использую статическую привязку, но в файле ядра содержатся инициализационные секции, привязанные к нижним адресам, и основные секции, привязанные к верхним адресам.

Если кратко, то да. Вообще основной исполняемый модуль приложения может быть перемещаемым, но в этом нет особой нужды. Лично я для подобных модулей использую формат файла, который в принципе не поддерживает релокацию (однако имеет поле для хранения базового адреса, правда, ядро все равно не "проглотит" любой адрес, а часто ему нужен вполне определенный адрес; я уже очень давно компилирую приложения только по адресу 400000h). Некоторые используют формат с поддержкой релокации, но только ради унификации формата основных модулей и библиотек.

Получается, что для процесса важен не сам адрес процесса, а адрес каталога страниц, после загрузки которого в CR3 адрес будут с 0. А функция добавления памяти будет добавлять страницы из любого места оперативки и ставить подряд в каталоге страниц.
Как я понял, главный каталог страниц = 4мб, а для процессов можно делать и меньше.