Comments 5
Идея для такой абстракции хороша и показывает себя (возможность запустить ядро как приложение — это круто). Но память в реальных условиях абсолютно никогда не является кучкой байт/страниц/блоков, идущих по очереди. У меня есть опыт разработки x86_64 ядра, и я уверенно скажу, что память может (и будет) иметь дырки, разреженные области, служебные области и тд и тп. Bitmap/bump аллокаторы хоть и просты, но категорически неликвидны в реальных условиях. Я бы посоветовал сделать хотя бы простой buddy, о всяких DMA зонах и прочем я вообще молчу. Так же интересно посмотреть, как тут будут абстрагированы paging, прерывания, системные вызовы и тд и тп (не забывай, втор, ты пишешь ядро, а не CLI-калькулятор).
Интересно посмотреть сколько занимает C++runtime в результирующем бинарнике и вообще на содержание символов в нем. Есть подозрение что с таким подходом 4МБ Вам не хватит. :)
успехов вам, надеюсь вы допилите первую демку )
раз за разом смотришь так, кто-то пишет ОС, неужели это не интересно, если нужно ОС почему обязательно делают форки, форки менеджеров пакетных, ведь это и оправдано выходным запросом если нужна ОС ), а по итогу это энтузиасты пишут ОС-ки или не только, интересно
по итогу это интересно только в образовательных целях почему-то, когда в другой ОС, свои правила или пакетном менеджере
Элегантный OSDev: Пишем ядро ОС на modern C++ без макросов. Часть 2 — PMM + Allocator