Привет, Хабр! Это Даша Волкова из МТС Диджитал. Несколько дней назад стало известно, что Ведсон Алмейда Фильо (Wedson Almeida Filho), ключевой участник проекта Rust for Linux, решил уйти из команды. О своем решении он объявил неожиданно для многих представителей как самого проекта, так и Linux-сообщества. Теперь переход ОС на Rust замедлится. Что случилось?
Почему ушел главный герой
Судя по всему, Фильо утомили второстепенные обсуждения в команде. По его мнению, участники распыляют усилия и ведут дискуссии, которые не имеют значения для самого проекта. Конечно, это мнение одного человека, но Фильо в проекте уже больше четырех лет. Он считает, что сообщество Linux «свернуло не туда», а в проекте стало слишком много «нетехнической чуши».
«Я ухожу из проекта. После почти четырех лет я обнаружил, что мне не хватает энергии и энтузиазма отвечать на нетехнические вопросы. Поэтому лучше оставить эту работу тем, у кого они еще есть», — заявил Фильо. И прокомментировал, что над Rust for Linux работают талантливые специалисты, несмотря ни на что.
Еще Фильо отметил, что избранного направления — перехода на Rust — нужно придерживаться и дальше. Просто потому, что этот язык позволяет снизить количество проблем с безопасным доступом к памяти.
Что это за проект
Впервые о Rust for Linux стало известно в 2020 году, и Фильо находился у истоков. Его участие в проекте — добровольное: это не основная работа, он софтверный инженер в корпорации Microsoft. Еще пару лет Фильо работал в Facebook и Google, причем в последней трудился с 2013 по 2022 год.
Главная цель Rust for Linux — переписать ядро Linux на языке Rust. Сейчас большая часть кода написана на С и на ассемблере. По мнению ряда членов сообщества, ядро Linux слишком «дырявое» в плане безопасности. Убрать большинство угроз можно при помощи такого надежного языка с приоритетом на безопасность, как Rust. Помимо безопасности, Rust еще и предлагает отличную поддержку параллелизма.
Это мнение большинства участников проекта Rust for Linux, включая и Киса Кука из команды Google Security Team. Он, как и Фильо, один из ключевых участников. Соответствующая работа по избавлению ядра Linux от наследия прошлого в виде кода на С ведется уже давно. Еще в 2023 году, начиная с версии 6.1, была добавлена начальная инфраструктура Rust как альтернативного языка для создания новых модулей ядра. А в версии 6.5 появились новые абстракции и дополнительные подсистемы.
Rust как безопасный для памяти язык устраняет проблемы вроде переполнения буфера и зависших указателей. Снижается количество ошибок, не говоря уже об уязвимостях.
Какие сложности есть сейчас
Не все участники сообщества разработчиков Linux знают Rust, и это проблема. Недавно Линус Торвальдс прокомментировал, что разочарован скоростью внедрения Rust в Linux, а еще отметил, что большинство разработчиков работает с С и не планирует учить новый язык.
К тому же сам по себе Rust тоже не панацея. Недостатки у проекта тоже есть:
Нельзя целиком и полностью переписать ядро на Rust. В некоторых случаях приходится идти на компромиссы между производительностью и безопасностью.
Дополнительные рантайм-проверки приводят к проблемам с производительностью.
При переходе на новый язык неизбежно возникают проблемы организационного характера. Кто-то не согласен с переходом, кто-то не планирует учить ничего нового и так далее. Появляются проблемы с согласованием основных и третьестепенных технических моментов. А это и порождает те самые нетехнические дискуссии, о которых говорил Фильо.
Некоторые участники комьюнити отказываются работать с Rust, потому что боятся что-то испортить. Специалистов по С в команде Linux гораздо больше, чем по Rust. И, как уже сказали выше, первые не видят смысла переходить на новый для себя язык. К тому же после ухода Фильо есть организационные сложности — например, предстоит заново настроить взаимодействие между отдельными разработчиками.
Тем не менее Фильо продолжает верить в будущее языков, которые безопасны для памяти, и считать, что именно эта особенность делает Rust полезным для ОС Linux. Но сам он возвращаться пока не собирается.
Комментарии (22)
neuroonet
11.09.2024 08:00+2Вот блин, похоже, у них реальные проблемы. А разговоров-то было, мы тут ждем результата, и на тебе
domix32
11.09.2024 08:00+2Оптимизация Linux
Rust в ядре никогда не подразумевал его оптимизацию. Это сделано в первую очередь ради безопасности и эргономичности.
Он считает, что сообщество Linux «свернуло не туда»
Чувак выгорел бодаясь с религиозными сишниками. Асахи Лина тоже пободалась с одним из ментейнером касательно кривости некоторой подсистемы, который NACKнул её PR без каких-либо весомых аргументов "потому что новый код нинужон", в итоге решила драйвер мака писать почти полностью на Rust. Надеюсь, что хотя бы у Охеды дела неплохо идут.
maquefel
11.09.2024 08:00Асахи Лина тоже пободалась с одним из ментейнером касательно кривости некоторой подсистемы, который NACKнул её PR
А ссылочку можно на мэйл листы ?
domix32
11.09.2024 08:00Историю можно начать отсюда. Там есть сопутствующие ссылки по обсуждениям.
maquefel
11.09.2024 08:00+3Внимательно прочитал, честно говоря не знаю как реагировать на это всё. В ядре можно найти много примеров дискуссий как в одну так и в другую сторону.
Но такие масштабные шоу на публику большая редкость.
In the end, Asahi Lina gave up on using the DRM scheduler at all; the plan now is to reimplement that functionality within the Rust code using workqueues instead.
При чём все это произошло УЖЕ на стадии RFC...
В итоге получается на счету, на данный момент, один НОВЫЙ драйвер (https://lwn.net/Articles/987140/), который человек не поленился и дотащил до победного конца.
Если посмотреть на ситуацию в целом (листы вполне можно стянуть полностью):
git clone --mirror http://lore.kernel.org/rust-for-linux/0 rust-for-linux/git/0.gitПолучается, что с 2020 года:
1) Новых драйверов было предложено не более 10 (реально я насчитал меньше, но пусть будет так)
2) Большинство закачивает на стадии первого патча, даже не отвечая на вопросы мантейнеров
3) Практически нет корпоративных почтовых адресов, то есть получается компании не заинтересованы в драйверах на RUST
Без относительности хорошо RUST для ядра или плохо - может проблема в комьюнити rust-for-linux ?
domix32
11.09.2024 08:00Новых драйверов было предложено не более 10
Собственно знаю только о трёх.
Первый - эксперимент по переписыванию какого-то древнего почти ненужного драйвера - считай первая обкатка инфраструктуры которую влили в ядро. Сам драйвер скорее мёртв чем жив, строк там тоже с гулькин нос и профита тогда никто разглядеть не смог, ибо код там получался практически идентичный, за исключением нескольких проверок, которые пропали в Rust за ненадобностью.
Второй - NVME драйвера, который тоже POC для дипломной бакалавра, нежели контрибуция в ядро.
Ну и третий - драйвер для графики для яблочных устройств, который Асахи сама же реверсила и сама же писала для своего яблочного линукса. Тут, если читали сами мэйлисты, то должны быть в курсе, что "и так сойдёт" в качестве аргумента к NAK на третий раз уже не вызывает желания пытаться прислать исправленные патчи ибо любые аргументы начинают игнорироваться после того как Rust засветился в тексте.
Практически нет корпоративных почтовых адресов, то есть получается компании не заинтересованы в драйверах на RUST
Корпорации редко допускают экспериментирования такого рода, так что не удивлён. Собственно и контрибутеров по той же причине не сказать чтобы сильно много - старое работает, не трогай, а нового пока ещё не скрафтили.
maquefel
11.09.2024 08:00+2Второй - NVME драйвера, который тоже POC для дипломной бакалавра, нежели контрибуция в ядро.
Если я правильно помню, то это не драйвер, а обвязка, которая позволит создать драйвер. Если это действительно так - то это подпадает под общее правило "улучшений которые никто не использует".
Опять же смотрим https://lwn.net/Articles/987140/ - это улучшения И ДРАЙВЕР которые их использует - так можно, абстрактную инфраструктуру, которая не используется - нельзя (что не жаль и логично).
Ну и третий - драйвер для графики для яблочных устройств, который Асахи сама же реверсила и сама же писала для своего яблочного линукса. Тут, если читали сами мэйлисты, то должны быть в курсе, что "и так сойдёт" в качестве аргумента к NAK на третий раз уже не вызывает желания пытаться прислать исправленные патчи ибо любые аргументы начинают игнорироваться после того как Rust засветился в тексте.
Вынужден обвинить вас в излишней симпатии к этой девушке. Реально мы имеем мантейнера, который по правилам отвечает за всё на что он ставит reviewed-by тэг и человека который заявляет, что без этих исправлений в подсистеме драйвер не взлетит (ты то теперь взлетишь, а все остальные как ?), после чего привлекает армию людей никак не вовлеченных в разработку ядра для раскрутки хайпа. Ну такое себе...
domix32
11.09.2024 08:00+1Вынужден обвинить вас в излишней симпатии к этой девушке.
В таком случае и к тому чуваку из видео с его ржавым локом, который целый час не мог дальше первого слайда уйти. Но да, я не контрибутор, так что любая из сторон конкретно с меня не имеет никакого профита.
maquefel
11.09.2024 08:00+1Вопросы к знатокам:
1)
нельзя целиком и полностью переписать ядро на Rust.
Почему кстати говоря ?
2)
Rust как безопасный для памяти язык устраняет проблемы вроде переполнения буфера и зависших указателей.
А есть что-то такое, что не обнаруживает KASAN, KMSAN и прочие инструменты ядра, но обнаруживает RUST ?
3) Какой итоговый размер получается ядра - с растом и без ?
domix32
11.09.2024 08:00+2Почему кстати говоря ?
Если всё дружно обернуть в unsafe, то можно, но не нужно. Если делать ядро идиоматическим то это получится несколько иное ядро, нежели текущий Линукс. Можете сравнить структуру ядер например вот тут, redox и собственно непосредственно самого Linux. Идея раста в ядре - формализовать некоторые базовые структуры, которые затем можно будет достаточно единообразно использовать в драйверах и юзерлэнде. Сейчас струкутура поддержки кода линукса представляет собой несколько параллельных вотчин в каждом из которых есть некоторый свод неписанных правил, которым необходимо следовать как при использовании, так и при отправке патчей. Видео про лок из статьи - один из примеров подобного: при полусотне различных файловых систем нет единообразного абстрактного слоя, который могли бы использовать все файловые систем (по аналогии с HAL). Собственно попытка кодифицировать правила использования и представить некоторый ржавый интерфейс встречена с боем, воем, обвинением в ржавой ереси и примерно никаким прогрессом.
А есть что-то такое, что не обнаруживает KASAN, KMSAN
Все санитайзеры работают в рантайме, что для большинства требует дополнительной инструментации кода при сборке. В случае c Rust - многие из проблем, который возможно задетектить при помощи этих инструментов резолвятся ещё на этапе компиляции - оно просто не соберётся, если ты не сможешь доказать корректность работы с памятью. Конечно не панацея, но если оно скомпилировалось, то с большой вероятностью проблем с памятью в этом коде нет. А если они и есть, то наверняка они в сишном коде, который под капотом. Собственно история драйвера Лины как раз из этой оперы.
Могут быть другие проблемы - дедлоки все ещё не до конца решённая проблема, хотя в классическом виде она также решается также на этапе компиляции. Плюс есть косяки с компилятором и лифтингом времени жизни, что может приводить к use-after-free и прочим сегфолтам, но вроде как компилятор Rust в процессе рефакторинга, после которого эту проблему исправят. Случайно изобрести аналог в ядре несколько проблемно. Ну и есть всякие ржавые инструменты типа того же miri, плюс есть некотрая надежда на альтеративные компиляторы.
3) Какой итоговый размер получается ядра - с растом и без ?
По идее не сильно больше чем будь оно на Си - код работает с no_std/no_main, так что код не должен раздуваться.
maquefel
11.09.2024 08:00Спасибо за ответ, тем не менее:
Сейчас струкутура поддержки кода линукса представляет собой несколько параллельных вотчин в каждом из которых есть некоторый свод неписанных правил, которым необходимо следовать как при использовании, так и при отправке патчей.
Ни разу не замечал, есть более строгие подсистемы например clk, pinctrl и dt, а есть, так скажем, более мягкие, где закрывают глаза на недочеты, но при этом в более мягких нельзя рассчитывать, что "и так сойдет".
Все санитайзеры работают в рантайме, что для большинства требует дополнительной инструментации кода при сборке. В случае c Rust - многие из проблем, который возможно задетектить при помощи этих инструментов резолвятся ещё на этапе компиляции - оно просто не соберётся, если ты не сможешь доказать корректность работы с памятью. Конечно не панацея, но если оно скомпилировалось, то с большой вероятностью проблем с памятью в этом коде нет.
Отчасти согласен, но вся эта прелесть конечно не снимает необходимость тестирования во время которого гарантировать отсутствия таких ошибок может например KSAN.
По идее не сильно больше чем будь оно на Си - код работает с no_std/no_main, так что код не должен раздуваться.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC как например это происходит сейчас https://habr.com/ru/news/537100/.
domix32
11.09.2024 08:00+1Ни разу не замечал, есть более строгие подсистемы <>
Скажем, телега не совсем моя ибо я патчи в ядро не слал, только наблюдал попытки прислать ржавый код и показать примеры как оно могло бы быть. Аргументы "против" от ментейнеров линукса звучат примерно также как и желание RIIRнуть даже бога, даже аллаха. Более внятные аргументы были в недавнем обсуждении о добавлении Rust в ядро FreeBSD, который по большому счёту упирается в отсутвие ментенеров, готовых заниматься поддержкой его в системе и потенциальные проблемы с двоецарствием, как когда-то было с Perl.
которого гарантировать отсутствия таких ошибок может например KSAN.
Оно всё ещё содержит огромное количество Си кода, так что интеграция с ним никуда не исчезает, также как и фаззеры ядра. Возможно, в каких-то ситуациях оно может и поможет найти проблемы с вызовом кода из Си - то бишь FFI с кучкой unsafe. Непосредственно в Rust ошибки, за которыми охотится KASAN/KMSAN инвалидируются на этапе компиляции via borrow checker.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC
Не очень понимаю связь между размерами бинарей и поддержкой SoC в ядре. Встроенка на расте существует, в том числе и bare metal, halов тоже понаписть успели под популярные процессоры/платы. Видел энтузиастов, которые делали бэкпорт под какой-то DOS с 16 битным int, Gameboy и какие-то ещё. То есть скрафтить кастомный таргет не выглядит, как что-то невозможное. В остальном нужна поддержка кодогенерации из LLVM IR под целевую платформу. А пока трех тиров хватает всем.
maquefel
11.09.2024 08:00Ваша точка зрения понятна, отчасти согласен - человеку не вовлеченному в разработку ядра может быть трудно объективно посмотреть со стороны.
Не очень понимаю связь между размерами бинарей и поддержкой SoC в ядре.
Банально нет места под ядро большего размера (памяти нет, флэша не хватает, старый загрузчик), они уже постепенно отмирают по этой причине (ядро всё таки растёт в размерах).
Tim7456
11.09.2024 08:00+2нельзя целиком и полностью переписать ядро на Rust.
Почему кстати говоря ?Ядро Линукса сейчас - это несколько тысяч человеко-лет работы.
Кто будет вкладывать столько ресурсов?
Кто будет координировать эту прорву работы? И ради чего? Такая работа далека от удовольствия.
maquefel
11.09.2024 08:00Вопрос был к знатокам RUST, про технические трудности со строны RUST, а не про целесообразность как таковую.
Tim7456
11.09.2024 08:00Так это и есть трудности со стороны RUST. Языковых то трудностей нет. Уж на чем только ядра не писали, даже на JavaScript'е. А вот у сообщества RUST есть столько инженеров такого уровня, чтоб этот проект потянуть?
Причем там же весьма узкие специалисты нужны. Там неспроста ругань с мантейнером файловых систем была. Он RUST учить не хочет, и он в своем праве. А заменить его некем. Немного на планете инженеров которые могут высокопроизводительные драйвера файловых систем писать и поддерживать. И вот нет такого инженера который может и в драйвера, и в RUST, еще и согласен эту ношу на себя взвалить.
Недостаток инженерных ресурсов необходимого уровня - это техническая трудность или какая?
redsh0927
11.09.2024 08:00Ну и человека, который вложил жизнь в создание линупса, можно прекрасно понять. Человека с мозгами. Через 5 лет опять придумают какой-нибудь хрюст и окажется что всё опять надо на полпути переделывать. И ядро превратится в помойку. Любители руста/хрюста/зига/етц тихонько свалят, рассказав что были вынуждены уйти из-за "нетехнической ерунды", а люди, вложившие жизнь и душу в создание ядра на Си останутся с загаженной помойкой.
Торвальдс правильно говорит, пусть ржавчина хотя бы пройдёт проверку временем - там посмотрим.
И проблема не в том, что "сделать невозможно". В теории на любой Тьюринг-полной хреновине можно хоть крузис запустить, и ядро можно хоть на брейнфаке сделать. Но сишники привыкли решать задачи прямым и оптимальным путём, а тут наваливают кучу рандомных ограничений. Из-за чего приходится извращаться чтобы просто сделать какую-то очевидную вещь. Часто получая неоптимальные структуры данных из-за необходимости угождать капризам языка. Либо загаживать код всякими ансейфами просто чтобы иметь возможность просто сделать то что требуется. Уникальность в Си в том что он не накладывает никаких ограничений. Делай то что нужно, так как нужно. Рустов можно нагородить сколько угодно, потому что каждая собака норовит придумать свой набор ограничений и навязать своё видение. Опять же, любителям ржавчины никто не мешает написать своё ядро с блэкджеком и шлюхами и доказать миру что это круто, а не портить то на что другие много жизней потратили. И не надо рассказывать что из-за отсутствия миллиардов легаси-дров нет смысла и начинать. Пусть сделают биндинг-леер чтобы можно было грузить модули от линупса.
funny_falcon
11.09.2024 08:00Я читал, что он был не главным и не самым активным.
Но одним из трёх, так что это всё равно потеря.
yokotoka
11.09.2024 08:00
dplsoft
11.09.2024 08:00+1если грубо, то у меня возникает впечатление что "носятся с rust, как с дураки с писаниной торбой". да и говорят про "не технические вопросы", а сами ничего не делают в области снятия долговременных технических рисков.
почему я это утверждаю? потому что вместо того, что бы заняться снятием долговременных технических рисков с языком - а именно : подготовка стандарта языка, организация процесса тестирования "альтернативных реализаций языка" и "его-же новых версий" на предмет соответствия уже существующему стандарту - эти люди "на полном серьезе" рассуждают в бложиках, что им важнее "инклюзивный и гибкий процесс развития языка". (бложик где это звучало сейчас не подскажу, пишу с мобилы, но для интересующихся - дам в комментариях.)
стандартизация языка разработки на котором пишется система, контролируемость, плавность процесса его развития - это критичный для любой большой системы фактор на долгом периоде.
вспомним историю : хоть питон и руби. когда новые версии языка не позволяли перенести на них на них код уже написанной системы. у питоновцев, к их чести, совести хватило не бросить старую версию и она до сих пор её тянут. а у разработчика руби - не хватило - он прекратил поддержку старых версий, "и да он знает что многие не могут перейти на новую версию потому что это надо глубоко перерабатывать систему".
ну и вот : подумайте : что будет с ядром линукса, когда в языке, не обложенном стандартами, тестами, контролируемым процессом принятия изменений, вдруг, "по решению инклюзивного сообщества" решат что надо что-то критически поменять, сломав совместимость со старой версией? а вы уже всё ядро уже переписали на этот язык и под его старую версию. что будет ?
сначала перед вами станет проблема рефакторинга и снова переписывания всего - а это время и деньги; а потом - станет проблема безопасности, потому что когда производитель прекратит выпуск патчей безопасности под старый компилятор - вы сядете в лужу.
и отсутствие в rust альтернативных совместимых компиляторов, в том числе и от коммерческих производителей - это важный признак неготовности языка и среды его поддержки к использованию в больших и серьезных проектах.
а теперь хотите страшного? представьте в сообществе rust пару менеджеров майкрософта ? и на фоне наличия описанных технических рисков - вся эта "шумиха и движ" по части переписывания ядра Линукс на руст, ... тут как бы вообще создается впечатление целенаправленного саботажа.
а неоднократное уже появление "истерик" по поводу "нас не оценили мы ходим" (не первый раз же происходит , кстати) - вообще возникают ассоциации совсем с другими, процессами.повторюсь : если осуществить описанный выше сценарий со "сломом обратной совместимости языка" в условиях, когда на нем уже переписано ядро - вся линукс-экосистема сядет в лужу.
и пока у языка нет стандарта, механизмов проверки соответствия стандарту и процесса принятия изменений с учетом этого стандарта - эти риски не то что не иллюзорны - именно к ним, фактически, целенаправленно, различные руст-активисты и пытаются привести. осознанно или нет - это другой вопрос.
так что не надо называть разработчиков ядра "ретроградами" и "староверами". они то как раз очень хорошо понимают к чему может привести переход на язык разработки, у которого нет стабильности и хоть каких-то гарантий по части ровного "недерганного" развития.
ialexander
Смысл повторять уже опубликованное неделями позже? Новость - не вино, ей не нужно выстаиваться.
https://habr.com/ru/news/840520/