Почему я пишу собственную операционную систему
Я решил написать серию статей про свою операционную систему - Триалогия.
Не потому, что миру срочно нужна ещё одна ОС. Этого добра и так хватает. Просто в какой-то момент мне стало интересно, смогу ли я вообще довести такую штуку до состояния, где она действительно загружается, рисует экран, запускает процессы и не разваливается сразу после старта.
И постепенно проект перестал быть просто экспериментом "на выходные".
Если долго возиться с софтом, рано или поздно начинаешь смотреть ниже привычного уровня абстракций. Сначала просто из любопытства. Потом ловишь себя на мысли, что хочешь понимать, что происходит между нажатием кнопки питания и появлением рабочего стола.
- Как процессор вообще находит код загрузчика.
- Как ядро переключает задачи.
- Как память внезапно перестаёт быть "просто указателями".
- Почему вывод одного пикселя иногда требует неожиданно много возни.
У многих на этом этапе появляется идея "а не написать ли свою ОС". Обычно она так идеей и остаётся. И это нормально: объём работы там очень быстро перестаёт быть смешным.
Снаружи всё выглядит романтично. На практике ты сидишь ночью и пытаешься понять, почему после включения paging система внезапно уходит в triple fault без единого сообщения. Или почему обработчик клавиатуры ломает стек раз в двадцать загрузок.
Таких проектов уже огромное количество. Учебные ядра, pet-project’ы, эксперименты студентов, старые хобби-репозитории на GitHub, которые не обновлялись годами. Есть и серьёзные вещи - Minix, исследовательские системы, специализированные микроядра.
Мой проект где-то далеко в хвосте этого списка, и я не пытаюсь делать вид, будто изобретаю что-то новое.
Но одну вещь я довольно быстро заметил: очень многие OSDev-проекты заканчиваются почти сразу. Люди доходят до загрузчика, выводят текст на экран - и всё. Или начинают слишком рано строить красивую часть системы: окна, мышь, анимации. Хотя планировщик задач ещё не работает нормально, память течёт, а половина ядра держится на временных костылях.
Я и сам периодически наступаю на это.
Поэтому в какой-то момент решил идти скучным путём: сначала базовые механизмы, потом всё остальное. Не потому, что это "правильно", а потому, что иначе проект просто разваливался.
Из-за этого долгое время система выглядела очень непрезентабельно.
Чёрный экран, логи, примитивный терминал, периодические зависания. Но зато внизу постепенно появлялось что-то устойчивое. Что в прочем не мешало после очередной переделки начинать процесс стабилизации сначала.
Окна и рабочий стол появились сильно позже.
Почему эта серия устроена именно так
Большинство материалов про написание ОС идут снизу вверх: первый загрузчик, переход в protected mode, простейшее ядро - и дальше шаг за шагом.
Я решил сделать немножко наоборот.
Система уже существует в (полу)рабочем состоянии. Её можно загрузить. Есть рабочий стол, окна, файловая система, базовый userspace. Что-то работает нормально, что-то пока очень сыро, но это уже не набор отдельных экспериментов.
Поэтому сначала я хочу показать текущее состояние проекта таким, какое оно есть сейчас. Без попытки превратить всё в идеально выстроенный учебник.
Где-то архитектура получилась удачной. Где-то нет. Некоторые решения я сегодня вообще не стал бы повторять. Часть подсистем до сих пор переписывается на ходу. Как сказал один близкий мне человек (привет Антон ) - Нужна ракета, проектируй ракету. Но было уже поздно, я хотел ракету а спроектировал самолет, который затем пришлось напильником доводить. И это еще не раз аукниться.
И мне как раз это кажется интересным - не финальная "правильная" картинка, а сам процесс, вместе со всеми ошибками и переделками.
Систему можно запустить самому
Это не просто набор скриншотов.
Образ системы можно скачать и запустить у себя - в QEMU или VirtualBox. Я отдельно распишу настройку и процесс сборки, потому что там пока хватает шероховатостей.
Сразу предупрежу: проект нестабилен!
Иногда система грузится идеально. Иногда намертво зависает ещё до инициализации рабочего стола. Бывает, что после очередного изменения драйвера внезапно перестаёт работать то, что до этого неделю было стабильным.
Сейчас это скорее стройка, чем готовый продукт. Но мне самому наблюдать за этим состоянием интереснее всего. Когда система ещё меняется буквально каждую неделю (месяц), а любое крупное (и даже иногда мелкое) изменение может потянуть за собой цепочку неожиданных проблем.
Зачем вообще всё это
Главная причина довольно простая: мне это нравится.
На работе почти всегда есть ограничения - совместимость, сроки, чужая архитектура, старые решения, которые уже нельзя трогать. Даже хорошие проекты со временем обрастают правилами и инерцией.
Здесь ничего этого нет.
Если я хочу полностью переделать scheduler - я просто иду и переделываю scheduler. Если мне кажется, что какой-то механизм лучше реализовать неудобным или странным способом ради эксперимента - я могу это проверить. Иногда оказывается, что идея была плохой. Иногда наоборот.
Но именно эта свобода и держит проект живым.
Что будет дальше
В следующих статьях я постепенно разберу, как система устроена сейчас:
- загрузка,
- устройство ядра,
- память и процессы,
- драйверы,
- графическая подсистема,
- userspace,
- файловая система,
- и всё остальное, что успело появиться или сломаться по дороге.
Без особой романтизации. Включая вещи, которые пришлось переписывать несколько раз.
Оставайся рядом
Если это тебя зацепило - если хочешь узнать, как Триалогия выглядит изнутри, что работает, а что у меня прямо сейчас горит синим пламенем, следи за следующими статьями.
В следующей части покажу текущее состояние Триалогии подробнее - что уже работает, а что пока существует в режиме "не трогай, оно держится на честном слове".
◀ Предыдущая статья Содержание Следующая статья ▶
*Создано с использованием ИИ
*Система не стоит на месте, поэтому в дальнейшем тексты могут не совпадать с реальным положением