OSDev

Для доступа к самим таблицам нужно...
1. написать аллокатор страниц, т.е. учитывать свободные и занятые страницы.
2. перед включением виртуализации памяти подготовить таблицы PD и PT, в которых используемая в данный момент память (включая сами таблицы!) отображена сама на себя. Иначе не сможешь перейти в режим VM, сразу словишь исключение page fault.
3. загрузить адрес PD в CR3 и включить режим виртуальной памяти.
После этого можешь продолжать работать с таблицами и с данными, они все будут находиться по тем же адресам, что и раньше, т.к. их отобразили на те же адреса.

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

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

Потом попробую перенести ядро в верх, т.е скомпилировать его с org побольше и изменить его виртуальные адреса, а потом уже и процессы настроить.

Начинаем сначала - будет виртуальная память как в большинстве операционок широкого профиля или виртуальной памяти не будет (операционки реального времени, NetWare до 5-й версии и т.п.). Если виртуальная память будет, очень внятная книга по этому вопросу - М. МакКузик - FreeBSD: архитектура и реализация. В BSD виртуальная память от Mach и в этой книге она очень неплохо описана. В книге хорошо даны общие понятия - зачем делать то, что написали в этой теме (а всё что в этом топике - это уровень pmap в BSD - таблицы, страницы). Начинать-же надо сверху - что требуется от памяти: понятие процесс, регионы, отображения файлов, разделяемые объекты, анонимные, подкачка. Может быть - какая-то своя иерархия, но она должна быть. Иначе - не понятно как и куда двигатся.

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

Для себя я решил, что систем без MMU со страницами не существует Это базовое требование.
Хотя в природе безусловно - они есть...

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

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

Система может и есть, но ядра в обычном понимании этого слова нет. Больше похоже на графическую библиотеку на голом железе.

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

Это работает ровно до тех пор, пока в игру не вступают устройства с DMA, которые работают с физическими адресами и которым нужны буфера, непрерывные в физической памяти.

Я так и думал, что возникнет такой вопрос, кстати если заполнить массив с низу в верх, то впереди будут адреса верхних страниц(участков памяти по 4096 байт), и работа начнётся с ними в первую очередь, а в начале массива с нижними адресами. Я имею в виду что на этот случай можно создать доп. функцию и она может искать нужный объём страниц перебором, главное, чтобы работала быстро первая функция как постоянно востребованная, а вторая нужна редко и в основном при загрузке системы, когда все страницы пусты и ещё не перемешаны.