Возможно, стоит вернуться к микроядрам

Короткий безымянный пост на notes.hella.cheap - примерно страница текста без бенчмарков и кода. Это скорее набросок аргументации, а не проектный документ, и читать его стоит именно так: тезис узок и поддаётся проверке, а текст не претендует на большее количество доказательств, чем у него есть.

Определение, на которое он опирается, вполне компактно: микроядро оставляет в ядре только планирование, управление доступом к устройствам ввода-вывода и IPC, а всё остальное выносит в userspace.

Доводы в пользу, сформулированные конкретно

Изоляция с точки зрения безопасности - первый аргумент. В микроядре ошибка в одном драйвере даёт атакующему лишь эту подсистему (или вовсе только этот драйвер), а не всю систему целиком.

Надёжность - второй аргумент, и примером здесь служит CrowdStrike. На Windows с микроядерной архитектурой сбой 2024 года лишь лишил бы часть специалистов по безопасности телеметрии, а не попал на первые полосы газет, поскольку упавший компонент утянул бы за собой только себя.

Третий аргумент организационный, а не технический. Будь Linux микроядерной системой, команде ядра не пришлось бы принимать каждый драйвер под каждое устройство и проверять код, ревью которого требует экспертных знаний по внутреннему устройству каждого чипа, поддерживаемого Linux. Это переосмысляет политику приёма драйверов как следствие архитектуры ядра, а не выбор модели управления.

Почему это не прижилось

В 80-е и 90-е появилось множество микроядерных операционных систем, и препятствием, с которым они столкнулись, стали накладные расходы. В посте чётко указана причина: компьютеры той эпохи не позволяли процессу из userspace обращаться к физическому устройству напрямую. Поэтому серверу файловой системы для чтения с диска приходилось делать системный вызов, что означало переключение контекста, а оно влекло за собой дорогостоящие блокировки и копирование между адресными пространствами.

В этом и заключалось всё возражение, и ставка автора в том, что это было следствием ограничений тогдашнего оборудования, а не свойством самих микроядер.

Почему сейчас

IOMMU уже около десяти лет являются стандартом для ПК. При грамотном использовании IOMMU и разделяемой памяти, по утверждению автора, переключения контекста можно полностью исключить из основного сценария (happy path) и практически свести на нет в целом, если допустить небольшую задержку. Основной сценарий здесь определён как случай, когда ядер достаточно, чтобы вся необходимая работа выполнялась уже запущенными процессами.

В проекции на три задачи ядра:

Планирование похоже на гипервизор Xen: перед микроядром, построенным на технологиях виртуализации, стоят те же задачи, что и перед гипервизором, а IOMMU входит в этот технологический стек.

Доступ к устройствам ввода-вывода управляется аппаратно через IOMMU. В этом и заключается суть аргумента, и именно этого элемента не хватало архитектурам 1990-х годов.

Для IPC нужны лишь два примитива: возможность выделять разделяемые буферы между процессами и целочисленный атомарный compare-and-swap. Разделяемый буфер становится очередью команд - кольцевым буфером, где поставщик (producer) и потребитель (consumer) сдвигают указатели начала и конца атомарными операциями. Сообщения передаются асинхронно без переключения контекста, без копирования между адресными пространствами и без блокировок. В посте отмечается, что это не теория: драйверы GPU уже работают именно так.

Разделяемые библиотеки обрабатываются в стиле экзоядра. Если процессы ОС фактически представляют собой гостевые VM, то библиотеки можно линковать в программу при запуске и реализовывать локально всё, чему не нужно пересекать границы процессов. В качестве подтверждения приводится наблюдение: любое приложение и так поставляет копию собственной операционной системы в виде Electron, поэтому избыточные копии библиотек в памяти уже не создают таких накладных расходов, как тридцать лет назад.

Оценка сложности реализации намеренно скромна. Xen уже предоставляет большую часть уровня гипервизора. Для серверов можно скопировать подход Mach, а код сети и файловых систем взять из FreeBSD. Подсистема DRM уже построена вокруг асинхронных буферов команд, так что графическую подсистему Linux можно вынести в userspace практически как есть, возможно, объединив дисплейный сервер в одном процессе с ней.

Что остаётся за рамками аргументации

Утверждение об IPC является опорным и при этом наименее проработанным. Формула "всё, что нужно, - это разделяемые буферы и атомарный CAS" описывает транспорт, а не протокол поверх него, тогда как транспорт никогда не был сложной частью после устранения копирований. microkernel-ipc-design разбирает рабочий дневник Сэйи Нуты (Seiya Nuta) ровно по этой проблеме проектирования в FTL, и сложности там совсем в другом: синхронный IPC взаимно блокируется, как только два сервера пытаются отправить данные друг другу, поэтому в FTL добавляется паттерн notify-and-pull; драйвер, проталкивающий (push) пакеты в сервер TCP/IP, сталкивается с проблемой противодавления (backpressure), поэтому FTL инвертирует схему в опрос (pull); а ограничение очереди по числу запросов в обработке (in-flight), а не по объёму данных, - это то, что не даёт кольцу стать вектором для DoS. Lock-free кольцевой буфер не даёт ответов ни на один из этих вопросов. Нута приходит к тому же выводу в стиле io_uring, на который намекает пост, но проходя через вопросы управления потоком (flow control), которые пост пропускает.

Утверждение о производительности также не подкреплено цифрами. Фразы вроде "практически устранить переключения контекста, если вы готовы смириться с небольшой задержкой" изобиловали в литературе по микроядрам 90-х годов, и именно их в итоге опровергли бенчмарки. Аппаратная предпосылка надёжна и проверяема; вывод же из неё просто декларируется.