TL;DR Уже пишут, на C++17 написано ядро Zircon, ОС Fuchsia.
Если ты программист на C/C++, то наверняка тебя на собеседовании спрашивали, или даже может быть ты спрашивал других, вопрос, чем может быть плохо писать ядро ОС или ядерные модули на C++, или просто, почему так не делают? Сегодня я хотел бы немного подискутировать на эту тему, особенно в свете новостей о выпуске Fuchsia OS на устройствах Google Nest Hub.
Всё началось в далёком 2016, когда на GitHub появился загадочный репозиторий, из кода которого следовало, что Google работает над разработкой новой ОС под названием Fuchsia. Впервые официально Google заговорил о Fuchsia на конференции Google I/O 2019, представив официальный сайт. Код отличался от Android и Chrome OS тем, что не был основан на ядре Linux, а на собственном ядре, которое сначала называлось Magenta, а потом Zircon. Ядро специально проектировалось, чтобы охватить весь спектр платформ, от встроенных RTOS систем, и мобильных платформ, до настольных ПК, тем самым порождало слухи о возможной замене в будущем Android и Chrome OS. Графический пользовательский интерфейс и приложения пишутся на фреймворке Flutter с использованием языка программирования Dart.
Ядро Zircon родилось из проекта ядра реального-времени для встроенных устройств Little Kernel (LK). С одной стороны, Zircon можно назвать микро-ядерной архитектурой, в той степени, что там реализована концепция коммуникаций между компонентами, на основе отправки сообщений, с другой стороны, минималистическим ядро также сложно назвать, например, там реализовано более 170 системных вызовов, почти как в монолитном ядре. Что ещё примечательно, авторы черпали вдохновения из UNIX систем, при этом концепцию сигналов они полностью игнорировали, но поддержали паттерн событийно-ориентированного программирования, и постарались сделать так, чтобы системные вызовы не переводили процесс в сон, и вместо работы с файловыми дескрипторами, всё сводится к манипуляции с разными объектами.
Меня заинтересовало то, что ОС Fuchsia, и само ядро Zircon, почти полностью, написано на современном C++17, с ассемблерными вставками, когда надо работать напрямую с “железом”. Вообще, использование C++ для разработки встроенных систем, реального времени, создание игр, не такая уж и редкость. Применяя C++ в таких ограниченных системах, приходится полностью отказываются от исключений, динамического определения и приведения типов, также часто нельзя позволить себе автоматическое динамическое выделение памяти, вместо этого пишутся вручную оптимизированные решения. Это похоже на то, с чем сталкиваются разработчики ОС Fuchsia, но последние пошли дальше и стали использовать C++ в коде ядра.
Строго говоря, так как C++ является надмножеством языка C, т.е. все программы на C можно собрать компилятором C++, то если из языка C++ не использовать все его “фишки”, то мы “деградируем” до нашего доброго C. Примерно по такому же пути пошли разработчики Fuchsia и Zircon, если очень хочется, то можно, они составили список фич, которые нельзя использовать из C++, а также в режиме ядра полностью запрещено использовать стандартную библиотеку из пространства std. Взамен, предлагается оптимизированная библиотека Fuchsia Base Library (FBL), которую можно использовать как в ядре, так и в пользовательском пространстве. Да, часть драйверов может работать в пользовательском пространстве, что немного снимает ограничения на использование библиотек, но это уже на усмотрение разработчика, например, код инициализации и чтения конфигурационных файлов выполняется не часто, поэтому можно позволить себе излишества.
Добавить немного герметика (Hermetic C++). Разработчики ОС Fuchsia приняли решение, использовать чистый C API, а не C++, внутри ядерных модулей, в системных вызовах, в динамически подгружаемых модулях ядра, во всех официально экспортируемых библиотечных API. Сделано это с целью предотвращения “съезжания” ABI, а также для возможности связки с другими языками (language binding), опять же с C++, или Dart/Go/Python/Rust.
Возвращаясь к вопросу на собеседовании, почему не пишут ядра на C++? Ой, я вас обманул, кажется, и не ответил напрямую. В качестве домашнего задания предлагаю подтянуть матчасть про API/ABI и ответить по списку, что вынудило разработчиков Fuchsia отказаться от следующих C++ фич? Или имеет смысл отдельный пост(ы) про каждый?
Exceptions
RTTI and dynamic_cast
Operator overloading
Virtual inheritance
Statically constructed objects
Trailing return type syntax
Exception: when necessary for lambdas with otherwise unutterable return types
Initializer lists
thread_local in kernel code
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Я считаю, что писать ядро ОС на C++ это…
-
16,7%В ногу со временем (стильно, модно, молодёжно)2
-
33,3%После всех наложенных ограничений теряются все плюсы использования C++4
-
0,0%Нет, только C0
-
66,7%Rust же! Redox тому пример.8
