OSDev

Я думаю, что тогда раздачу физических секторов организовать в обработчике 13го прерывания.

Кстати 4мб страницы это очень полезная вещь, так как для создания окон для доступа к регистрам эта тема очень подходит. Например я открыл такое окно для апика и лапика, они находятся по умолчанию в 1019ом 4мбайте 0FEC00000 и 0FEE00000.
Я просто mov dword[6FECh],0FEC00000h or 10000011b вот этой строчкой открыл 4мб окно и всё, и ненужно тратить страницу для таблиц. Адреса устройств кстати выравнены на 4мб и их тоже открывают 4мб окнами без потерь лишних страниц.

В пространстве задач таких окон не будет, чтобы они могли использовать все 4Гб, т.е. задачи которые используют их будут работать в первой задаче(системы), которая использует это виртуальное пространство.

Кстати говоря, действительно, одна из задач страничной адресации это управление адресным пространством в котором находится оперативная память и память от контроллеров, причём у нас есть карта областей оперативной памяти и областей памяти контроллеров. Память от контроллеров нам нужно просто открыть в системном пространстве не меняя их адресов и не используя для этого страницы оперативной памяти, а область оперативной памяти разбить на страницы и записать в массив.
После этого мы можем создавать пространство для задачи с небольшой областью от ядра и пустым пространством без дырок, в котором по требованию задачи будут выделяться страницы из массива свободных страниц расположенных в любом месте областей оперативной памяти.
Задаче при запросе куска памяти находим в её пространстве место, даем ей адрес этого места, и размечаем его так, что при чтении или записи в неё (у нас вызовется прерывание 13ое) туда запишется страница оперативной памяти, а если часть памяти запрошенной не будет востребовано, то мы ничего не теряем.
Опять же в самом физическом пространстве могут быть любые дыры и области, а нам это не повредит, так же мы можем смело выделять память для задач больщее необходимого(с запасом).
Например если я знаю максимальный размер необходимого размера памяти(например 4мб), но в зависимости от конфигурации мне может потребоваться всего 3 страницы или все 1024, так я просто выделю 4мб, а если буду пользоваться только 3, то и потратится только 3. Причём востребованы могут быть 1-5,8-9,11.
Так же было бы очень полезно те страницы, которыми мы воспользовались, но не храним в них нужную информацию отдавать, возвращая метку "выделить по востребованию". И конечно вариант меток страниц сброшенных на диск с их адресом на диске у неактивных задач при нехватке страниц.

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

У меня все это отображается в пространстве ядра. Ты говоришь только о коде ядра небольшого размера, отображаемом во все ВАП, но это близко к микроядерной архитектуре, которой у тебя не наблюдается. Так что привыкай к тому, что пространство ядра будет занимать половину/четверть ВАП каждой задачи. По разметке ВАП первичная задача обычно не отличается от все других задач. У меня в этом плане она отличается только тем, что при ее завершении ВАП не уничтожается полностью, а очищается для возможной повторной загрузки основного модуля.

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

Благодарю за участие в обсуждении такой сложной темы, как я понял нужно отключать кеширование аппаратных буферов единицей в 4 бите, а зачем, где лучше использовать кеширование?
Т.е. для регистров контроллеров отображённых в адресное пространство нужно так открывать mov dword[6FECh],0FEC00000h or 10010011b

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

Для использования графического процессора можно открыть интеловские спеки и использовать его, в чём проблема.

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

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

Некоторые функции для работы с памятью у меня вообще отключают страничную память на время выполнения, для работы с реальными адресами понадобилось.

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

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

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

Вполне естественно, что памятью нужно управлять по-разному в прикладном пространстве и в пространстве ядра. Я не использую замещение памяти для кода и данных ядра. Даже секции резервирования обычно используются в ядре не для подключения страниц по требованию, а просто для резервирования пространства. Большая часть резерва (как у основного модуля ядра, так и у драйверов) обычно используется как раз-таки под объекты ядра/драйверов. Таблицами объектов с размером структуры от 4 байт до 16 кб ядро может управлять самостоятельно, причем не только своими, но и принадлежащими драйверам. Таблицы могут быть фрагментированы в ВАП и иметь переменный размер. В области локальных данных ядра часто используется копирование по записи, т.к. в ней передаются локальные таблицы объектов и большинство др. структур данных от родительских процессов дочерним. Управление памятью в прикладном пространстве - это вообще отдельный разговор.

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

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