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++, а также в режиме ядра полностью запретили использовать стандартную библиотеку из пространства 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
ссылка на оригинал статьи https://habr.com/ru/post/559294/
Добавить комментарий