Всем доброго времени суток. Я наткнулся на проект — Cosmos (позволяет писать реальное ядро на C#, об этом позже), и начал на него копать. Понял, что на самом деле, это штука, которая позволяет писать ядро так, будто это просто приложение, хоть и с намного большей ответственностью, почти не задумываясь о железе и ассемблере, только о логике. Это безусловно круто, но лишает человека единственной мотивации хвататься за OSDev — понимания компьютера и контроля. Многие за этой целью идут, некоторые садятся на Cosmos, некоторые сами мучатся с C++, bare metal и в целом дышат настоящим OSDev‘ом. В этой статье мы рассмотрим основные проблемы «настоящего OSDev», и абстрагированного от железа, но не менее интересного OSDev.
В чем конкретная проблема слишком потянутой за уши абстракции над железом?
На первый взгляд все нормально. Вы создаете класс, наследуете его от Cosmos.System.Kernel, реализуете два метода — BeforeRun() и Run(). Начинаете писать, например, свой мини‑терминал. Используете, как ни в чем не бывало, обычные функции WriteLine(), ReadLine() и так далее. Реализовали даже продвинутый парсер команд, прям как у настоящих ОС. Потом уходите в реализацию настоящего ядра и оболочки: ваша ОС позволяет запускать приложения, работает с сетью, есть антивирус, но нет никакого комьюнити. Деньги, слава, популярность у вас почти в руках. Но есть одно большое но — вы почти не понимаете, как это все реально работает. Будь ваша ОС достаточно популярной, всегда найдется человек‑тестер, который будет тестировать ваше творение на прочность. Будет вам писать, что здесь все ломается, например, при тысяче потоков и тысяче открытых одновременно файлов. Но проблема это не ваша — это проблема кода ниже, который обслуживает как раз ФС и многопоточность, возможно проблема еще глубже. Как повезет. И вот тогда перед вами встанет выбор — либо все переписывать, либо заканчивать проект.
Я описал нереалистичный, но показательный сценарий развития событий, чтоб примерно донести свою мысль. Основная проблема в том, что вы не понимаете при разработке, что вообще происходит. Слепо доверять можно только на позиции прикладного разработчика, не системного. Ответственность выше, задачи другие.
Вторая проблема заключается в производительности. Ни для кого не секрет, что даже гениальный IL2CPU, который использует Cosmos, не способен обогнать современные GCC/Clang/MSVC, знающие свое дело и прошедшие через десятилетия колоссальных испытаний.
Человек идет в OSDev за трудностями, пониманием и несет в себе огромную мотивацию. Иногда он хочет исправить существующие проблемы, иногда просто так. Но нельзя бояться сложностей, иначе вы либо не будете, либо будете, но медленно развиваться в этой области. Слишком высокая абстракция скрывает, например, принципы работы аллокатора, переключение контекста и в целом понижает ставки и интерес.
Слишком высокая ответственность. Да, Cosmos разрабатывали гениальные инженеры, но его не проверяли миллионы сумасшедших разработчиков, ежедневно его использующих, в отличие от C++ компиляторов. Действия от лица ядра, например, позволяют отключить троттлинг, повысить частоту процессора и уйти в вечный цикл. Что будет? В худшем случае, ядро или весь процессор моментально сгорят, в лучшем — спасут великие умы Intel/AMD и других производителей, которые регулярно исследуют такие страшные сценарии, но это не снимает ответственность с ядра ОС. Если сильно захотеть — можно пробраться в гипервизор или даже SMM‑режим, вот тогда кремниевому другу не поздоровится, но статья не об этом. Таких багов конечно может и не быть, но это примерное описание доверия компьютера ядру и его почти никем неоспоримых возможностей.
Получился довольно большой блок. Часто необычные проблемы и гейзен‑баги — не ваши проблемы, а проблемы кода ниже, который вы уже исправить не сможете.
Что же делать?
Этот вопрос одновременно простой, и сложный. Самый частый и верный вариант — начинать все с полного нуля. Да, это сложно. Да, это долго. Но это позволит вам все‑таки реально понять, как работает это чертово изобретение.
Единственная проблема «правильного пути» в том, что это очень отпугивает мотивированных, но не наполненных знаниями об ассемблере и кросс‑компиляторах людей. Некоторые справляются: иногда с DeepSeek/ChatGPT, иногда с Google в руках и SO.
И тут я решил попробовать сделать базу — написал небольшой загрузчик, настроил тулчейн и дал минимальный набор команд программисту — write(char, x, y), getchar(), readsector(uint64_t), writesector(uint64_t, char* data). В целом получилось круто — я сам попробовал, прикольно.
Зачем? Начал я эту всю тему чисто чтобы друга ввести в OSDev, но он не прям круто шарит в программировании. Я постарался от него максимально оградить всю тяжесть, которую нужно помнить, но оставил только тяжесть, над которой надо думать, а именно логику.
Подведем итоги
Здесь я разжевал кучу проблем, постарался максимально все сделать понятным. Свой проект я афишировать не буду — это чисто доказательство того, что на самом деле сложность можно разделить на железо и логику. Если вдруг интересны мои работы — мой GitHub в профиле.
Я ни в коем случае не говорю, что Cosmos плохой, я просто постарался снять розовые очки и сказать, что OSDev игрушка только в том случае, если вы попробуете и забудете эту неблагодарную, сложную, но уважаемую и интересную сферу.
ссылка на оригинал статьи https://habr.com/ru/articles/1044274/