OSDev

Спасибо, все замечания весьма по-делу. Вы мне облегчили задачу выбора. Чтобы обсуждать было проще, я начал с того, что слегка причесал, чтобы
выглядело хотя бы слегка читаемо и выложил всё на github: https://github.com/chesnokov/dev64-os

90% времени программист проводит в отладке. Поэтому отладку надо облегчить как можно сильнее. По поводу вывода информации на экран. Одни только регистры займут пол экрана(10 строк). Так что вывод информации лучше сделать интерактивным. По поводу обработки клавиатуры на первое время её лучше напрямую повесить на прерывания. Что бы не зависеть от ядра которое мы и хотим отлаживать, что бы ошибки ядра не влияли на отладку.
А заглушки не эффективны. С ними время вашей отладки будет стремиться к 99.9. Вам надо место локализовать и причину. Поэтому надо делать обработку ошибок полную. И надо сделать вывод строки в которой произошло исключение. И интерактивный просмотр внутренних структур. На написание такого отладчика вам понадобиться немного времени. Если вы пишете на си и delphi при компиляции можно создать map файл где детальная информация по строчкам и основным структурам.

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

Вопрос тупой.
Что касается как помечать, то помечай как терра инкогнито вернее как РАМ инкогнито.
Что касается игнорирования. То согласно принципу достаточности, то их надо игнорить ровно как и всё остальное. Только доступные для использования которые деляться на те которые ещё свободны и те которце уже заняты под ядро и программы.

PS. Прошу прощенья. За то что Я умничаю. Но честно по другому не вижу как объяснить.

Чего непонятного? Не использовать, как RAM. Вообще не учитывать не получится, потому что в дырах могут располагаться аппаратные буферы, а если при детекте по аналогии с дырами вы также проигнорировали и всякие специфические участки, то соответственно там также могут находиться ROM и ACPI-таблицы. Что мешает разделить учет RAM и учет дыр? У меня, например, за счет такого разделения экономится память.

Согласно принципу разделения я их не учитываю. Так и пусть располагаются. Их определение идет драйверами по другим методикам. ACPI буферы тоже драйверами. И работа с ними соответственно через отображение, мепирование на нужный участок виртуального адреса.

Если дыры делать занятыми участками RAM, то может оказаться, что придётся отслеживать всё адресное пространство, - в 64-битной архитектуре это недопустимо большой напрасный расход памяти. Традиционно, менеджер памяти собирает все фрагменты RAM и добавляет их в пул свободных страниц. Никаких дыр отслеживать не надо, есть просто список доступных страниц, а где они находятся физически - дело десятое.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

а можно ли просто забить на участки памяти с кодом 2 и тупо не включать их в мониторинг менеджером памяти? ну и соответственно забить на дыры

Не вижу для этого никаких препятствий.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>