OSDev

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

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

Кроме того, возможно, исходили из размещения всего прикладного кода с нулевого виртуального адреса. На практике от этого отказались: младшая страница виртуального адресного пространства для прикладного кода сделана недоступной, чтобы ловить попытки обращения по нулевым указателям (дополнительное средство ловли ошибок в приложениях).

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

В общем, размещать можно где угодно и как угодно, но для удобства программирования ядра необходимо, чтобы его виртуальные адреса не использовались прикладным кодом. Вполне можно делать так, как у Вас: ядро идёт с нулевых адресов, приложение -- где-то позже (например, с границы 1 Гбайта). Более того, такой подход лично мне кажется более разумным: в любом случае надо блокировать доступ задач к самым младшим адресам памяти (для отлова нулевых указателей, как уже говорил выше), так что для них эти виртуальные адреса по-любому должны быть недоступными, так почему бы там не начать ядро?

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

Спасибо за ответ. Тогда, пожалуй, оставлю как есть.

Разница есть и весьма существенная. Можно легко менять баланс между размерами прикладного пространства и пространства ядра без релокации или перекомпиляции приложений.

Забыл упомянуть. Я использую Long Mode, на процесс выделяю 512 гигабайт виртуальной памяти. Думаю, под систему можно зарезервировать хоть 4-8-16 гигов, и никаких проблем в ближайшие лет 50 не возникнет.:) Зато когда системный код в начале памяти, можно без проблем поставить тождественное отображение для системы и работать фактически с физической памятью, если понадобится. Тем более, что собираюсь делать как раз приложения с возможностью релокации или же позиционно-независимые.

Вы действительно так думаете?

Да, так. Даже винде на код ядра хватает намного меньше 4 гигов (сколько уж я не знаю, но если там 4 гига виртуальной памяти, и юзает она намного меньше). Не говоря уже о том, что у меня руки отвалятся писать16 гигабайт кода.:)

Во-первых, определись 4 или 16 гиг. Во-вторых, этого (может быть) мало. В-третьих, даже если выберешь 16, в один прекрасный момент этого станет мало, т.е. опять приходим к обозначенной мной проблеме. В-четвертых, иметь возможность релокации приложений и постоянно это делать - далеко не одно и то же - что больше некуда потратить вычислительные ресурсы? К тому же не следует отказываться от возможности иметь исполняемые файлы, вообще не содержащие данных для релокации. Лично мне в прикладном пространстве релокация по-настоящему нужна только для библиотек. Про тождественное отображение вообще не понял. Кто тебе мешает сделать какой-нибудь системный процесс и в его прикладном пространстве реализовать тождественное отображение? Может, лучше честно признаемся, что сделали, как было проще, и теперь нет никакого желания что-либо переделывать :)

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

Да, я сделал проще. Желание переделать было бы, если б я увидел действительно серьезные плюсы.
По поводу "сделать системный процесс с тождественным отображением" - не пойму, как. Ведь при переключении виртуальной памяти код должен находиться в одном и том же виртуальном адресе. Если для этого процесса поставить тождественное отображение - значит и физический адрес должен быть равен виртуальному. И как тогда это сделать, если на компе 4 гига оперативки, а весь системный код спроецирован на 512й гигабайт? Можно конечно там сделать кусочек с нетождественным отображением, и переключать через него, но тогда можно считать точно так же: "А кто сказал, что физическая память не станет больше 512 гигов? Тогда ведь часть адресов будет недоступна для нашего системного процесса." Объясните этот момент, пожалуйста. Тогда может пойму смысл, и переделаю.
В отображении в нулевые адреса сейчас проблемы не вижу. А в отображении в конец - вижу. Просто не хочу создавать лишние трудности лишь ради того, что вдруг системная часть будет весить больше 16 гигов (имхо - система с таким количеством кода и дров толком не работоспособна).
Для аппаратных буферов у меня в конце пара сотен страничек есть глобальных.:)