OSDev

Все верно.

Ладно, вопрос про виртуальную память исчерпал себя. Предлагаю вернуться вот к этому:

Кто как решает?

А о какой конкретно управляющей информации идет речь?
"Выделялка" физических страниц оперирует с заранее известным набором данных (я предполагаю, что количество ОП не меняется в процессе работы:)), следовательно, размер фиксирован.
Часть кода, которая ассоциирует виртуальную страницу с физической, опять же, оперирует с заранее заданным набором таблиц страниц, находящихся в определенном месте, + заданными служебными данными для ускорения поиска свободной страницы для мапа, но эти служебные данные тоже имеют фиксированный размер и могут быть выделены единоразово при создании нового ВАП.

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

Edit: допустим для простоты, что менеджер физ.памяти не привязан ни к какому ВАПу.

Вот простейший вариант. У нас битмап. При старте ОС мы определяем общее кол-во памяти: X гигабайт. Для битмапы X гигабайт нужно Y байт битовой карты. Значит мы заявляем, что по физическому адресу A будет находиться Y байт карты памяти. И карту памяти сразу создаем так, что она сразу содержит "занятые" страницы на системные нужды, т.е. прямо при формировании битовой карты мы начиная со страницы floor(A/size_of_page) и до адреса floor(A/size_of_page) + ceil(Y/size_of_page) ставим единички, а остальное помечаем ноликами. Проблема решена.

У меня сейчас страницы по 2 мегабайта, а не по 4 кб, поэтому битмап вполне применим даже на больших объемах памяти. И я при старте определяю, сколько мне понадобится занять памяти для базовых системных структур (таблицы GDT, IDT, битмап физ памяти, место под некоторые системные переменные и т.д.) и после этого сразу в памяти формирую битмап, в котором отмечены занятыми все страницы, в которые попадают системные данные. Потом я сливаю эти данные с таблицей "дырок" в ОП, получаемой от биоса. При этом я предполагаю, что некоторый объем памяти от 0 до определенных границ (уже не помню точно, каких) присутствует всегда. Да, я знаю, что при наличии шины ISA могут быть дыры в этом диапазоне, но я решил меньше придерживаться требований совместимости с настолько ископаемым оборудованием в изначально 64-битной ОС.

Другими словами, идея такова: мы предполагаем, что некоторая область физ.памяти всегда доступна; виртуально резервируем эту область, разворачиваем в ней структуры данных и фиксируем реальное использование.

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

Спасибо, понятно.

Участок который ссылается на самого себя помечается как не изменяемый.


Она не изменяемая куда она денется?
В виндоусе к примеру есть термин "невыгружаемая память".
От 4-50МБайт в зависимости от версии виндоуса.

В битовой карте-то? 3-м состоянием бита?

Куда денется память, которой не было (дырка, например)? Даже не знаю, что на это ответить.

Для этого можно завести еще "мини-карту", или просто сохранить номера неизменяемых страниц, их немного: минимум, зарезервированный системой, и дыры.
Проще всего, на мой взгляд, сохранить отдельно адреса регионов, которые не могут быть освобождены. В формате "номер начальной страницы + размер". Их будет не больше 5 как правило.
А у меня вообще есть память, которая распределяется динамически, а есть то, что недосягаемо простым смертным (ниже определенной границы памяти). Сама граница высчитывается при старте в зависимости от параметров железа и настроек ОС. И никто эту память никогда не освободит, даже если захочет.

Видимо надо вам всё разжевать. А ещё вам лучше выспаться. А то у вас слова не связанные.

1.
Процесс загрузки используем статическое распределение памяти как самый простой.
Статические распределение значит что диапазоны определены и не изменяются в процессе выполнения.
К примеру IBM вместе с Intel договорились что 0-сектор грузиться по адресу
по физическому адресу 07C00h-07DFFh.
То что видео память находиться по адресу 0A0000h-0BFFFFh

Следующим шагом было создание исполняемых файлов с секциями. Секции в основном 3-х видов: Стек, данные и код.
Можно вспомнить микроконтроллёры у которых эта память вообще физически разная и логически не пересекается. Т.е. для доступа используются отдельные команды.


При загрузке исполняемого файла загрузчик передает указатели в исполняемый код сообщая его место положение. А также указатель на стек и указатель на данные.

Далее секцию данные поделили ещё на несколько секций.
Статическая инициированная - которые защиты в исполняемый файл и загружаются в память без изменения.
Статическая обнуляемая - что-бы не хранить много нулей в файле
Динамические данные(куча) - то что изменяется во время исполнения.

Имеется в виду статические адреса с переменной базой. А сами значения переменных в ходе работы могут меняться. А вот у динамических данных меняются и адреса относительно базы кучи.

Как правило секции располагаются так: сначало стек исполнения, затем код,потом данные, в конце куча.
Стек исполнения имеет придел обычно 64 КБайта. Код и данные произвольный размер. Куча всё что осталось после размещения исполняемого файла в памяти.

2. Можно заметить что выше описанный метод использует принцип стека. Структуры разного размера располагаются одна за другой. Тем самым экономится память.
Да и загрузчик теперь может иметь произвольный размер.

Далее загрузчик определяет количество доступной памяти. Делает это он при помощи статической структуры. Как правило отводиться 256 структур вида SMAP под карту доступной памяти. Хотя уже можно использовать и стековый подход. Я использую стек.

Затем на основе этой карты вычисляется необходимый размер для менеджера памяти.
Это две структуры.
1. структура отвечающая за выделение и освобождение страниц. Вернее фреймов. Эта структура нужна что-бы отделить свободные страницы от занятых.
2 структура дерево страниц(корень, каталоги, таблицы страниц)

В структуре 1. Всё что было создано и загружено до этого помечается как не выгружаемая память и в качестве владельца задается "Загрузчик".
Также так как в этой структура ссылается сама на себя она тоже помечается как не изменяемая.

На всё это нужно 20-40 страниц. Т.е менее 1 МБайта который есть во всех компьютерах.

Затем в структуре 1 выделяется память под дерево страниц 2-рая структура. Она заполняется. В этом дереве также есть участки которые нельзя трогать. Их тоже помечаешь как защищенные. Сделать это можно по разному. В дескрипторе таблице есть биты. Можно и отдельно завести структуру.

Когда будешь делать функции для работы с этими структурами у тебя будет их 2- вида. Безопасные и не безопасные. Безопасные будут проверять входят диапазоны адресов в разрешенные к изменению или нет и вызывать небезопасный код для изменения данных в этих структурах.

Вкратце вот как-то так. Как было сказано в одной из книжек по Осдеву. Загрузчик это попытка вытянуть себя за волосы подобно тому, как это делал Барон Мюнхаузен.

Детально всё это поймёте как только будете сами делать ручками. В данном случае моё описание достаточно абстрактно. Видимо это в силу того что я сейчас активно изучаю ООП. А там способ мышления немного другой.

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

Навязывать свои решения тоже не стоит.