При инициализации моего ядра у меня есть несколько вещей, которые должны произойти: 1) необходимо включить подкачку страниц, 2) диспетчер физической памяти должен проанализировать карту памяти из grub, и 3) необходимо получить доступ к разному стартовому коду данные, которые должны остаться там на потом (например, GDT, IDT, структуры управления памятью).
Зависимости между этими шагами сводят меня с ума. С более высокой половиной ядро связано по своему виртуальному адресу, и поэтому я выбрал следующие варианты: 1) включить подкачку в сборке, что потребует следования всем указателям мультизагрузки (в сборке), чтобы они по-прежнему были доступны к диспетчеру физической памяти, а затем разархивировать их все, 2) связать код запуска по его физическому адресу и затем выполнить некоторые манипуляции с указателями для доступа к структурам ядра по их физическим адресам, или 3) не использовать верхнюю половину ядро.
Также включается загрузка менеджера физической памяти, не зная объема физической памяти во время компиляции. Я уверен, что мне нужно либо тщательно избегать всех мультизагрузочных структур при выделении первых структур, либо использовать их все сначала, а затем не беспокоиться о их перезаписи (хотя мне все равно придется иметь дело с модулями, и этот подход, вероятно, включает в себя копирование таблиц мультизагрузки в известное место по мере их необходимости при настройке менеджера физической памяти).
Именно из-за этих проблем я до сих пор избегал более половины ядра. У кого-нибудь есть хорошая система для разрешения этих зависимостей? Может быть, какой-то вариант этого трюка с GDT для доступа к ядру по его связанному / виртуальному адресу и к таблицам мультизагрузки по их физическому адресу, или к использованию каких-либо предварительно определенных таблиц страниц, которые позволяют избежать проблем, описанных выше, возможно, с участием PSE?