Комментарии 22
Смысл повторять уже опубликованное неделями позже? Новость - не вино, ей не нужно выстаиваться.
https://habr.com/ru/news/840520/
Вот блин, похоже, у них реальные проблемы. А разговоров-то было, мы тут ждем результата, и на тебе
Оптимизация Linux
Rust в ядре никогда не подразумевал его оптимизацию. Это сделано в первую очередь ради безопасности и эргономичности.
Он считает, что сообщество Linux «свернуло не туда»
Чувак выгорел бодаясь с религиозными сишниками. Асахи Лина тоже пободалась с одним из ментейнером касательно кривости некоторой подсистемы, который NACKнул её PR без каких-либо весомых аргументов "потому что новый код нинужон", в итоге решила драйвер мака писать почти полностью на Rust. Надеюсь, что хотя бы у Охеды дела неплохо идут.
Асахи Лина тоже пободалась с одним из ментейнером касательно кривости некоторой подсистемы, который NACKнул её PR
А ссылочку можно на мэйл листы ?
Историю можно начать отсюда. Там есть сопутствующие ссылки по обсуждениям.
Внимательно прочитал, честно говоря не знаю как реагировать на это всё. В ядре можно найти много примеров дискуссий как в одну так и в другую сторону.
Но такие масштабные шоу на публику большая редкость.
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 ?
Новых драйверов было предложено не более 10
Собственно знаю только о трёх.
Первый - эксперимент по переписыванию какого-то древнего почти ненужного драйвера - считай первая обкатка инфраструктуры которую влили в ядро. Сам драйвер скорее мёртв чем жив, строк там тоже с гулькин нос и профита тогда никто разглядеть не смог, ибо код там получался практически идентичный, за исключением нескольких проверок, которые пропали в Rust за ненадобностью.
Второй - NVME драйвера, который тоже POC для дипломной бакалавра, нежели контрибуция в ядро.
Ну и третий - драйвер для графики для яблочных устройств, который Асахи сама же реверсила и сама же писала для своего яблочного линукса. Тут, если читали сами мэйлисты, то должны быть в курсе, что "и так сойдёт" в качестве аргумента к NAK на третий раз уже не вызывает желания пытаться прислать исправленные патчи ибо любые аргументы начинают игнорироваться после того как Rust засветился в тексте.
Практически нет корпоративных почтовых адресов, то есть получается компании не заинтересованы в драйверах на RUST
Корпорации редко допускают экспериментирования такого рода, так что не удивлён. Собственно и контрибутеров по той же причине не сказать чтобы сильно много - старое работает, не трогай, а нового пока ещё не скрафтили.
Второй - NVME драйвера, который тоже POC для дипломной бакалавра, нежели контрибуция в ядро.
Если я правильно помню, то это не драйвер, а обвязка, которая позволит создать драйвер. Если это действительно так - то это подпадает под общее правило "улучшений которые никто не использует".
Опять же смотрим https://lwn.net/Articles/987140/ - это улучшения И ДРАЙВЕР которые их использует - так можно, абстрактную инфраструктуру, которая не используется - нельзя (что не жаль и логично).
Ну и третий - драйвер для графики для яблочных устройств, который Асахи сама же реверсила и сама же писала для своего яблочного линукса. Тут, если читали сами мэйлисты, то должны быть в курсе, что "и так сойдёт" в качестве аргумента к NAK на третий раз уже не вызывает желания пытаться прислать исправленные патчи ибо любые аргументы начинают игнорироваться после того как Rust засветился в тексте.
Вынужден обвинить вас в излишней симпатии к этой девушке. Реально мы имеем мантейнера, который по правилам отвечает за всё на что он ставит reviewed-by тэг и человека который заявляет, что без этих исправлений в подсистеме драйвер не взлетит (ты то теперь взлетишь, а все остальные как ?), после чего привлекает армию людей никак не вовлеченных в разработку ядра для раскрутки хайпа. Ну такое себе...
Вопросы к знатокам:
1)
нельзя целиком и полностью переписать ядро на Rust.
Почему кстати говоря ?
2)
Rust как безопасный для памяти язык устраняет проблемы вроде переполнения буфера и зависших указателей.
А есть что-то такое, что не обнаруживает KASAN, KMSAN и прочие инструменты ядра, но обнаруживает RUST ?
3) Какой итоговый размер получается ядра - с растом и без ?
Почему кстати говоря ?
Если всё дружно обернуть в unsafe, то можно, но не нужно. Если делать ядро идиоматическим то это получится несколько иное ядро, нежели текущий Линукс. Можете сравнить структуру ядер например вот тут, redox и собственно непосредственно самого Linux. Идея раста в ядре - формализовать некоторые базовые структуры, которые затем можно будет достаточно единообразно использовать в драйверах и юзерлэнде. Сейчас струкутура поддержки кода линукса представляет собой несколько параллельных вотчин в каждом из которых есть некоторый свод неписанных правил, которым необходимо следовать как при использовании, так и при отправке патчей. Видео про лок из статьи - один из примеров подобного: при полусотне различных файловых систем нет единообразного абстрактного слоя, который могли бы использовать все файловые систем (по аналогии с HAL). Собственно попытка кодифицировать правила использования и представить некоторый ржавый интерфейс встречена с боем, воем, обвинением в ржавой ереси и примерно никаким прогрессом.
А есть что-то такое, что не обнаруживает KASAN, KMSAN
Все санитайзеры работают в рантайме, что для большинства требует дополнительной инструментации кода при сборке. В случае c Rust - многие из проблем, который возможно задетектить при помощи этих инструментов резолвятся ещё на этапе компиляции - оно просто не соберётся, если ты не сможешь доказать корректность работы с памятью. Конечно не панацея, но если оно скомпилировалось, то с большой вероятностью проблем с памятью в этом коде нет. А если они и есть, то наверняка они в сишном коде, который под капотом. Собственно история драйвера Лины как раз из этой оперы.
Могут быть другие проблемы - дедлоки все ещё не до конца решённая проблема, хотя в классическом виде она также решается также на этапе компиляции. Плюс есть косяки с компилятором и лифтингом времени жизни, что может приводить к use-after-free и прочим сегфолтам, но вроде как компилятор Rust в процессе рефакторинга, после которого эту проблему исправят. Случайно изобрести аналог в ядре несколько проблемно. Ну и есть всякие ржавые инструменты типа того же miri, плюс есть некотрая надежда на альтеративные компиляторы.
3) Какой итоговый размер получается ядра - с растом и без ?
По идее не сильно больше чем будь оно на Си - код работает с no_std/no_main, так что код не должен раздуваться.
Спасибо за ответ, тем не менее:
Сейчас струкутура поддержки кода линукса представляет собой несколько параллельных вотчин в каждом из которых есть некоторый свод неписанных правил, которым необходимо следовать как при использовании, так и при отправке патчей.
Ни разу не замечал, есть более строгие подсистемы например clk, pinctrl и dt, а есть, так скажем, более мягкие, где закрывают глаза на недочеты, но при этом в более мягких нельзя рассчитывать, что "и так сойдет".
Все санитайзеры работают в рантайме, что для большинства требует дополнительной инструментации кода при сборке. В случае c Rust - многие из проблем, который возможно задетектить при помощи этих инструментов резолвятся ещё на этапе компиляции - оно просто не соберётся, если ты не сможешь доказать корректность работы с памятью. Конечно не панацея, но если оно скомпилировалось, то с большой вероятностью проблем с памятью в этом коде нет.
Отчасти согласен, но вся эта прелесть конечно не снимает необходимость тестирования во время которого гарантировать отсутствия таких ошибок может например KSAN.
По идее не сильно больше чем будь оно на Си - код работает с no_std/no_main, так что код не должен раздуваться.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC как например это происходит сейчас https://habr.com/ru/news/537100/.
Ни разу не замечал, есть более строгие подсистемы <>
Скажем, телега не совсем моя ибо я патчи в ядро не слал, только наблюдал попытки прислать ржавый код и показать примеры как оно могло бы быть. Аргументы "против" от ментейнеров линукса звучат примерно также как и желание RIIRнуть даже бога, даже аллаха. Более внятные аргументы были в недавнем обсуждении о добавлении Rust в ядро FreeBSD, который по большому счёту упирается в отсутвие ментенеров, готовых заниматься поддержкой его в системе и потенциальные проблемы с двоецарствием, как когда-то было с Perl.
которого гарантировать отсутствия таких ошибок может например KSAN.
Оно всё ещё содержит огромное количество Си кода, так что интеграция с ним никуда не исчезает, также как и фаззеры ядра. Возможно, в каких-то ситуациях оно может и поможет найти проблемы с вызовом кода из Си - то бишь FFI с кучкой unsafe. Непосредственно в Rust ошибки, за которыми охотится KASAN/KMSAN инвалидируются на этапе компиляции via borrow checker.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC
Не очень понимаю связь между размерами бинарей и поддержкой SoC в ядре. Встроенка на расте существует, в том числе и bare metal, halов тоже понаписть успели под популярные процессоры/платы. Видел энтузиастов, которые делали бэкпорт под какой-то DOS с 16 битным int, Gameboy и какие-то ещё. То есть скрафтить кастомный таргет не выглядит, как что-то невозможное. В остальном нужна поддержка кодогенерации из LLVM IR под целевую платформу. А пока трех тиров хватает всем.
Ваша точка зрения понятна, отчасти согласен - человеку не вовлеченному в разработку ядра может быть трудно объективно посмотреть со стороны.
Не очень понимаю связь между размерами бинарей и поддержкой SoC в ядре.
Банально нет места под ядро большего размера (памяти нет, флэша не хватает, старый загрузчик), они уже постепенно отмирают по этой причине (ядро всё таки растёт в размерах).
нельзя целиком и полностью переписать ядро на Rust.
Почему кстати говоря ?
Ядро Линукса сейчас - это несколько тысяч человеко-лет работы.
Кто будет вкладывать столько ресурсов?
Кто будет координировать эту прорву работы? И ради чего? Такая работа далека от удовольствия.
Вопрос был к знатокам RUST, про технические трудности со строны RUST, а не про целесообразность как таковую.
Так это и есть трудности со стороны RUST. Языковых то трудностей нет. Уж на чем только ядра не писали, даже на JavaScript'е. А вот у сообщества RUST есть столько инженеров такого уровня, чтоб этот проект потянуть?
Причем там же весьма узкие специалисты нужны. Там неспроста ругань с мантейнером файловых систем была. Он RUST учить не хочет, и он в своем праве. А заменить его некем. Немного на планете инженеров которые могут высокопроизводительные драйвера файловых систем писать и поддерживать. И вот нет такого инженера который может и в драйвера, и в RUST, еще и согласен эту ношу на себя взвалить.
Недостаток инженерных ресурсов необходимого уровня - это техническая трудность или какая?
Ну и человека, который вложил жизнь в создание линупса, можно прекрасно понять. Человека с мозгами. Через 5 лет опять придумают какой-нибудь хрюст и окажется что всё опять надо на полпути переделывать. И ядро превратится в помойку. Любители руста/хрюста/зига/етц тихонько свалят, рассказав что были вынуждены уйти из-за "нетехнической ерунды", а люди, вложившие жизнь и душу в создание ядра на Си останутся с загаженной помойкой.
Торвальдс правильно говорит, пусть ржавчина хотя бы пройдёт проверку временем - там посмотрим.
И проблема не в том, что "сделать невозможно". В теории на любой Тьюринг-полной хреновине можно хоть крузис запустить, и ядро можно хоть на брейнфаке сделать. Но сишники привыкли решать задачи прямым и оптимальным путём, а тут наваливают кучу рандомных ограничений. Из-за чего приходится извращаться чтобы просто сделать какую-то очевидную вещь. Часто получая неоптимальные структуры данных из-за необходимости угождать капризам языка. Либо загаживать код всякими ансейфами просто чтобы иметь возможность просто сделать то что требуется. Уникальность в Си в том что он не накладывает никаких ограничений. Делай то что нужно, так как нужно. Рустов можно нагородить сколько угодно, потому что каждая собака норовит придумать свой набор ограничений и навязать своё видение. Опять же, любителям ржавчины никто не мешает написать своё ядро с блэкджеком и шлюхами и доказать миру что это круто, а не портить то на что другие много жизней потратили. И не надо рассказывать что из-за отсутствия миллиардов легаси-дров нет смысла и начинать. Пусть сделают биндинг-леер чтобы можно было грузить модули от линупса.
Я читал, что он был не главным и не самым активным.
Но одним из трёх, так что это всё равно потеря.
если грубо, то у меня возникает впечатление что "носятся с rust, как с дураки с писаниной торбой". да и говорят про "не технические вопросы", а сами ничего не делают в области снятия долговременных технических рисков.
почему я это утверждаю? потому что вместо того, что бы заняться снятием долговременных технических рисков с языком - а именно : подготовка стандарта языка, организация процесса тестирования "альтернативных реализаций языка" и "его-же новых версий" на предмет соответствия уже существующему стандарту - эти люди "на полном серьезе" рассуждают в бложиках, что им важнее "инклюзивный и гибкий процесс развития языка". (бложик где это звучало сейчас не подскажу, пишу с мобилы, но для интересующихся - дам в комментариях.)
стандартизация языка разработки на котором пишется система, контролируемость, плавность процесса его развития - это критичный для любой большой системы фактор на долгом периоде.
вспомним историю : хоть питон и руби. когда новые версии языка не позволяли перенести на них на них код уже написанной системы. у питоновцев, к их чести, совести хватило не бросить старую версию и она до сих пор её тянут. а у разработчика руби - не хватило - он прекратил поддержку старых версий, "и да он знает что многие не могут перейти на новую версию потому что это надо глубоко перерабатывать систему".
ну и вот : подумайте : что будет с ядром линукса, когда в языке, не обложенном стандартами, тестами, контролируемым процессом принятия изменений, вдруг, "по решению инклюзивного сообщества" решат что надо что-то критически поменять, сломав совместимость со старой версией? а вы уже всё ядро уже переписали на этот язык и под его старую версию. что будет ?
сначала перед вами станет проблема рефакторинга и снова переписывания всего - а это время и деньги; а потом - станет проблема безопасности, потому что когда производитель прекратит выпуск патчей безопасности под старый компилятор - вы сядете в лужу.
и отсутствие в rust альтернативных совместимых компиляторов, в том числе и от коммерческих производителей - это важный признак неготовности языка и среды его поддержки к использованию в больших и серьезных проектах.
а теперь хотите страшного? представьте в сообществе rust пару менеджеров майкрософта ? и на фоне наличия описанных технических рисков - вся эта "шумиха и движ" по части переписывания ядра Линукс на руст, ... тут как бы вообще создается впечатление целенаправленного саботажа.
а неоднократное уже появление "истерик" по поводу "нас не оценили мы ходим" (не первый раз же происходит , кстати) - вообще возникают ассоциации совсем с другими, процессами.
повторюсь : если осуществить описанный выше сценарий со "сломом обратной совместимости языка" в условиях, когда на нем уже переписано ядро - вся линукс-экосистема сядет в лужу.
и пока у языка нет стандарта, механизмов проверки соответствия стандарту и процесса принятия изменений с учетом этого стандарта - эти риски не то что не иллюзорны - именно к ним, фактически, целенаправленно, различные руст-активисты и пытаются привести. осознанно или нет - это другой вопрос.
так что не надо называть разработчиков ядра "ретроградами" и "староверами". они то как раз очень хорошо понимают к чему может привести переход на язык разработки, у которого нет стабильности и хоть каких-то гарантий по части ровного "недерганного" развития.
Оптимизация Linux задерживается: ушел главный разработчик проекта Rust for Linux. Но почему?