Обновить

Элегантный OSDev: Пишем ядро ОС на modern C++ без макросов. Часть 2 — PMM + Allocator

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели9.6K
Всего голосов 6: ↑5 и ↓1+5
Комментарии6

Комментарии 6

Идея для такой абстракции хороша и показывает себя (возможность запустить ядро как приложение — это круто). Но память в реальных условиях абсолютно никогда не является кучкой байт/страниц/блоков, идущих по очереди. У меня есть опыт разработки x86_64 ядра, и я уверенно скажу, что память может (и будет) иметь дырки, разреженные области, служебные области и тд и тп. Bitmap/bump аллокаторы хоть и просты, но категорически неликвидны в реальных условиях. Я бы посоветовал сделать хотя бы простой buddy, о всяких DMA зонах и прочем я вообще молчу. Так же интересно посмотреть, как тут будут абстрагированы paging, прерывания, системные вызовы и тд и тп (не забывай, втор, ты пишешь ядро, а не CLI-калькулятор).

Да все верно. Я добавлю эти моменты в статью. Но более сложные аллокаторы оставлю на следующие статьи.

О bump allocator я упомянул, что он реализован как показать быстрый результат.

Интересно посмотреть сколько занимает C++runtime в результирующем бинарнике и вообще на содержание символов в нем. Есть подозрение что с таким подходом 4МБ Вам не хватит. :)

Бинарник занимает 11 КБ. Сейчас компиляторы умные, но шаблоны в любом случае дадут распухание.

успехов вам, надеюсь вы допилите первую демку )

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

по итогу это интересно только в образовательных целях почему-то, когда в другой ОС, свои правила или пакетном менеджере

Тупой вопрос, а почему не C++23 особенно когда стала появлятся адекватная поддержка модулей?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации