LINUX.ORG.RU

Кризис при продвижении языка программирования Rust в ядро Linux

 , ,

Кризис при продвижении языка программирования Rust в ядро Linux

2

5

В сообществе разработчиков ядра Linux возникли разногласия по поводу интеграции языка программирования Rust. Кристоф Хелвиг (Christoph Hellwig), мэйнтейнер подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC в ядре Linux, в своё время входивший в управляющий технический комитет организации Linux Foundation и выступавший истцом в связанном с GPL судебном разбирательстве с VMware, отказался подтверждать патчи, связанные с поддержкой разработки драйверов на языке Rust.

Предложенные патчи, добавляющие обвязки для функций подсистемы DMA, вызвали опасения относительно усложнения сопровождения кода и возможного снижения качества программного обеспечения. Некоторые разработчики предпочитают сохранять программные интерфейсы на языке C, чтобы избежать дополнительных сложностей.

В качестве причины отказа упомянуто усложнение сопровождения кода при наличии обвязок на других языках и желание сохранить программные интерфейсы к DMA в читаемом виде на языке Си, без размазывания по непонятным обвязкам. Кристоф предложил напрямую обращаться к исходному Си API DMA в каждом драйвере на языке Rust, чтобы не создавать дополнительных абстракций, от которых вынуждены будут зависеть сопровождающие ядра.

Неcмотря на высказанное разработчиками проекта Rust for linux намерение о полностью самостоятельном сопровождении написанной на Rust кодовой базы, на прием патчей было наложено вето.

Кристоф отметил, что если разработчики хотят добиться невозможности сопровождения Linux из-за смешивания в одной кодовой базе разных языков программирования, им следует делать это в своём драйвере, а не распылять эту «раковою опухоль» на основное ядро.

Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust. На первый взгляд кажется, что обвязки лишь надстройки над Си-структурами и функциями, которые никак не влияют на разработку и сопровождение кода на Си. Но это не так. При наличии подобных обвязок разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust. Многие сопровождающие не готовы брать на себя дополнительную ответственность за исправление проблем, возникающих в коде на Rust, и не намерены тратить своё время на отслеживание состояния Rust-обвязок.

>>> Подробности (OpenNet)



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от gaylord

Так в итоге получается что в половине подсистем раст будет, в половине - нет, работать нормально не будет, трудностей с поддержкой будет еще больше, и при этом все переругаются. Какой профит?

Линус поступил достаточно мудро

Да, переложил ответственность. Я бы понял когда так делают мейнтейнеры подсистемы, типа «я ниче не знаю идите к Линусу, как он скажет так и поступим», но вот когда лидер проекта так делает это (как по мне) очень странно.

micronekodesu ★★★
()
Ответ на: комментарий от zg

В Си не так много проблем. Как собственно и в Vim-е, например. Просто всё это не выстраивается в стабильную экосистему вида cargo install (или как оно там делается).

Основная проблема как раз в этом. Писать код не проблема. Всё кроме этого – да. И просвета нету. И не будет.

Демонтаж – единственный выход.

thegoldone ★★
()
Ответ на: комментарий от micronekodesu

Так в итоге получается что в половине подсистем раст будет, в половине - нет, работать нормально не будет, трудностей с поддержкой будет еще больше, и при этом все переругаются. Какой профит?

В такоим сценарии никакого. Но с чего ты взял, что «работать нормально не будет, трудностей с поддержкой будет ещё больше, и при этом все переругаются»?

Да, переложил ответственность. Я бы понял когда так делают мейнтейнеры подсистемы, типа «я ниче не знаю идите к Линусу, как он скажет так и поступим», но вот когда лидер проекта так делает это (как по мне) очень странно.

Это какая-то очень странная манипуляция. Мейнтейнеры всегда имели решающее право голоса относительно того, что принимать, а что нет. Линус влезает только когда все совсем плохо.

gaylord
()
Ответ на: комментарий от thegoldone

В Си не так много проблем.

Да вообще-то дохрена, мы просто привыкли и не замечаем сколько там ментальной нагрузки.

gaylord
()

Сишным дедам этот ваш Раст нафих не нужон. Финал был закономерен. Непонятно, зачем изначально это всё затевалось.

Если хочется писать на Rust - надо делать внешнюю обвязку-прослойку, не в апстриме и с ней уже взаимодействовать с Rust-а. Но это сложная задача, потому, что код в ядре меняется достаточно часто и эта обвязка будет ломаться, а при её фиксе надо будет и код на Rust фиксить. В силу особенностей Rust - возможно порой и переписывая большие куски. Никому это не интересно. Поэтому и такой проект без серьёзного финансирования завянет. А финансирования, похоже, нет. За качество платить никому не хочется.

vbr ★★★★★
()
Ответ на: комментарий от alysnix

сишники тут причем? им раст вообще не нужен

При том что им раст ломает сборку. Ну типа представь, лоровский сервер бы падал когда на форум через ie6 кто-то зашел. Или нашли дыру. Это ж не пользователи виноваты, а администраторы. Так и тут, код на C ломается от того что ломается сторонний код, который должен быть сбоку и не отсвечивать. То что код на расте в ту же репу коммититься - ну это особенность проекта, но это не должно все ломать.

я вот более чем уверен, что линуху этот раст кто-то навязал

А зачем? Не видно чтоб добавление поддержки раста что-то сильно поменяло. Думаю просто на хайпе протолкнули, типа чтоб ядро казалось стильным модным молодежным и инвесторы донатили больше. Был бы в это время популярен какой-нибудь питон или паскаль - с той же мотивацией можно было бы их вместо раста впихивать

micronekodesu ★★★
()
Ответ на: комментарий от gaylord

вы какое отношение имеете к си, и всякому там системному программированию?

alysnix ★★★
()
Ответ на: комментарий от gaylord

Zig никак не помогает тебе защититься от порчи памяти, а его метапрограммирование хуже, чем у C.

Тогда на nim. Там есть отслеживание границ и метапрограммирование сильно лучше чем у С.

Q-Master
()
Ответ на: комментарий от micronekodesu

Да, переложил ответственность. Я бы понял когда так делают мейнтейнеры подсистемы, типа «я ниче не знаю идите к Линусу, как он скажет так и поступим», но вот когда лидер проекта так делает это (как по мне) очень странно.

Ты видимо ни разу никем не руководил. Руководитель это не приниматор решений, а администратор процессов. Так что всё абсолютно верно, как по учебнику.

Clayman ★★
()
Ответ на: комментарий от Clayman

Руководитель руководителями. Линейный все-таки про решения.

gaylord
()
Ответ на: комментарий от thegoldone

В Си не так много проблем. Как собственно и в Vim-е, например. Просто всё это не выстраивается в стабильную экосистему вида cargo install (или как оно там делается).

Это ты уже другую тему начал - про экосистему, а не про сам язык. С ней в Си вообще жвах. Для того, чтобы собрать проект, особенно что-то из GNU, нужно запустить configure с массой порой неочевидных параметров и ещё подождать так нехило времени, пока оно отработает. И только затем можно запускать make. При этом у тебя уже должны быть все зависимости, как библиотечные, так и инструментарные. А если ты полезешь в сам этот проект что-то менять, тебе придётся доустановить всякие Autotools и прочее, причём обязательно конкретные старые версии, чтобы всё это (включая configure) нормально сгенерировалось и затем собралось. Деды к этому всему привыкли, а следующее поколение справедливо воспринимает как анальное изнасилование и отторгает.

zg
()
Ответ на: комментарий от gaylord

Но с чего ты взял

Ну потому что иначе быть не может. Если говорят «для ядра можно писать на rust, но» и дальше огромный список исключений и с кем надо договариваться то это значит что нормальной разработки на rust нет. Надо чтоб все в одну сторону гребли чтоб был успех. Или расту выделить какую-то свои изолированную ото всех песочницу, но тогда уже не скажешь что раст полноценно в ядре.

Линус влезает только когда все совсем плохо.

Но общее видение проекта он же задает? И одно дело когда там мейнтейнеры спорят как переменную назвать, другое - случаи типа как сейчас, когда происходят значительные, пусть не столько в качестве, сколько в пиаре, изменения.

micronekodesu ★★★
()
Ответ на: комментарий от mx__

претензии в основном эстетического характера из-за общей закорюченности и декларативные макросы перлятиной пованивают, но семантически парсится заметно легче, ну и не со стороны сишно плюсишного болотца за синтаксис предъявлять хуже чем у них только пёрл какой-нибудь А вот что действительно троллинг так это синтаксические УБ в сишечке, вот зачем такое может понадобиться? Да как это вообще возможно, у сишечки что грамматика противоречивая или что?

zurg
()

Я тут в другой теме спросил, может здесь спецов больше?

Что делает инсталятор nvidia, применительно к закрытому модуля ядра в дровах, при установки этих дров (к примеру из run)?

mx__ ★★★★★
()

...отказался подтверждать патчи, связанные с поддержкой разработки драйверов на языке Rust...

Правильно сделал.

Не вижу кризиса. Вижу желание развалить работы по ядру.

sparkie ★★★★★
()
Ответ на: комментарий от Clayman

Ты видимо ни разу никем не руководил.

Ни разу

Руководитель это не приниматор решений, а администратор процессов.

А кто принимает решения тогда и кто несет за это ответственность? Разве не руководитель? Если я сам принимаю решения и сам за них отвечаю то за что он тогда ходит в костюме, жмет руки и зарплата у него больше?

micronekodesu ★★★
()
Ответ на: комментарий от zg

Деды к этому всему привыкли, а следующее поколение справедливо … отторгает

Вместо выбрасывания Си уже нашли компромисс: перевести сборку на питон meson (GNOME & Co). mpv раньше был на waf (тоже питон).

gag ★★★★★
()
Ответ на: комментарий от micronekodesu

Ну потому что иначе быть не может.

«Это было неизбежно» — ментальная ловушка.

Если говорят «для ядра можно писать на rust, но» и дальше огромный список исключений и с кем надо договариваться то это значит что нормальной разработки на rust нет.

Почему нет? Как разработчиков драйверов видео заботит что сетевики не хотят? Это вообще разные люди, никак не пересекающиеся.

Но общее видение проекта он же задает? И одно дело когда там мейнтейнеры спорят как переменную назвать, другое - случаи типа как сейчас, когда происходят значительные, пусть не столько в качестве, сколько в пиаре, изменения.

Я же говорю, вы все просто увидели громкий заголовок и врали в истерию. Там подобные драмы — обычный вторник. Все выйдут подышать, успокоятся и что-нибудь решат.

gaylord
()
Ответ на: комментарий от mx__

Компилирует вокруг бинарных *.o файлов модуль-обвязку, который зовет из них функции.

gaylord
()
Ответ на: комментарий от Clayman

Ты видимо ни разу никем не руководил. Руководитель это не приниматор решений, а администратор процессов. Так что всё абсолютно верно, как по учебнику.

Интересно что это за учебник такой? Если Вам интересно то решения принимают ВСЕ, даже человек у которого нет никого в подчинении тоже принимает решения.

mx__ ★★★★★
()
Ответ на: комментарий от micronekodesu

А кто принимает решения тогда и кто несет за это ответственность?

Мейнтейнеры подсистем.

gaylord
()
Ответ на: комментарий от gag

Вместо выбрасывания Си уже нашли компромисс: перевести сборку на питон meson (GNOME & Co). mpv раньше был на waf (тоже питон).

То есть для сборки минимальной системы, а это не только ядро, нужно ещё и Питон тащить в этот зоопарк с идиотским GNU Autotools. Почему GNU Autotools всё ещё не на помойке, по крайней мере в основных проектах GNU? Даже CMake был бы принципиально лучше!

zg
()
Ответ на: комментарий от zg

meson дар от б-га. Он решает все проюлемы автолулзов, сам генерирует нужные файлы для clangd и умеет собирать тебе зависимости через wrap файлы.

gaylord
()
Ответ на: комментарий от gag

нашли компромисс: перевести сборку на питон meson (GNOME & Co). mpv раньше был на waf (тоже питон)

Этим испокон веков занимаются. Сейчас просто фаза под названием Meson.

Смысл сборки и управления зависимостями в двух трёх командах вида build/get/update. Никакой Meson этого не даст

thegoldone ★★
()
Ответ на: комментарий от zg

Они всё равно его захватят, скорее всего просто форкнув ядро со временем. Старое поколение стареет и начинает уходить. Продолжать разработку старыми методологиями и инструментами будет просто некому. По крайней мере в прежнем объёме. Корпорации переключатся на форк и перестанут поддерживать оригинальное ядро. Без корпораций любой проект такого уровня просте нежизнеспособен. А без достаточного количества людей, способных и интересующихся копанием в технологиях 80-х - тем более.

Ядро это на 90% драйверы. Железячники тупые и Rust не осилят. Они и С осиливают весьма условно. Поэтому такой план не сработает.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

у меня вот 4 устойчивых утверждения

  1. в системном софте проблема работы с памятью не стоит настолько остро как прикладном - в системщине аллокация на куче или любым нетривиальным аллокатором - это скорее исключение из правил. лучше такое вообще не допускать в силу больших вычислительных затрат и не вполне нормированном времени операции.

  2. средняя квалификация рустовиков в области железа, ос и системщины, куда ниже квалификации сишников в этом самом деле.

  3. синтаксис и семантика си много проще того же самого у руста.

  4. фичастость руста выше фичастоси си, отсюда возникают как проблемы с его мультиплатформенностью, так и размером рантайма. на си вот можно вообще писать без рантайма, прям на голом железе. причем «рантайм» там будет занимать два-пять экраничков. то ест два-пять экранчиков, плюс сликованный выхлоп от сишного компилятора, и вы пускаете код на новом железе. просто НОВОМ железе, которое вы сами спаяли из контроллера из стиральной машины, и памяти подобранной на помойке.

достоинства си для системщины - малый рантайм, малая фичастость, способствующая переносу языка и поделий на другие платформы, простота синтаксиса и семантики.

короче те фичи, что есть в русте (вплоть до утф8 строк и всяких там мэпов и коллекций и динамических масивов) - для системщины не нужны.

руст позиционировали куда-то в нишу голанга и прочих свифтов, то есть область прикладных задач с мусоросборкой. чтобы всех там раскидать по скорости в силу отказа от мусоробскорки. но видимо не взошло. тогда полезли в системщину - а там руста не надо. задачи не те.

alysnix ★★★
()
Ответ на: комментарий от gaylord

Но он написан на Питоне. С Питоном есть две принципиальные проблемы:

  • Плохая совместимость вниз даже внутри одной мажорной версии. Для примера, что-то работающее в 3.6 может перестать работать в 3.10. А если его починят, всё равно может перестать работать в 3.13
  • Питон не является частью проекта GNU. CMake тоже не является, но его можно легко и относительно быстро собрать из сорцов, без притаскивания мегатонн зависимостей.

Я в принципе не против Meson, но он больше подходит для сборки прикладного софта, а не системного. IMHO

zg
()
Ответ на: комментарий от vbr

Ядро это на 90% драйверы. Железячники тупые и Rust не осилят. Поэтому такой план не сработает.

Вывод: rust не годится для драйверов.

mx__ ★★★★★
()
Ответ на: комментарий от zg

Ну, раньше без перла было никуда, хотя и сейчас в Debian так. А теперь добавился питон. Но что касается meson, то тут энтузиасты пытаются решить эту зависимость, реализовав его синтакс на Си: boson.

gag ★★★★★
()
Ответ на: комментарий от gaylord

Это уже не так важно, главное чтобы не автолулзы. Это кошмар надо заканчивать.

Для тех, кто имел дело со всем этим ранее. А для тех, кто не имел, сборка проекта выглядит как whatever build. Что-то большее – муть.

thegoldone ★★
()
Ответ на: комментарий от zg

Но он написан на Питоне.

Да, и это плюс. Питон есть буквально везде.

Плохая совместимость вниз даже внутри одной мажорной версии. Для примера, что-то работающее в 3.6 может перестать работать в 3.10. А если его починят, всё равно может перестать работать в 3.13

Это касается языка, а не софта. Сценарии пишутся на некотором общем сабсете который этому не подвержен.

Питон не является частью проекта GNU.

Да и плевать, GNU мертв.

gaylord
()
Ответ на: комментарий от vbr

Железячники тупые и Rust не осилят.

в том и дело, что у железячников основная куча знаний навалена в области регистров, портов, уартов, всяких там протоколов, стрелок осциллорафа и паяльников. и куча там довольно большая.

и если им притащить еще и этот ваш чудаковатый руст, чтобы все это программировать, они бросят в вас чемнить тяжелым.

alysnix ★★★
()
Ответ на: комментарий от gaylord

Ну как нет, вон Гектор Мартин уже хлопнул дверью, а это знаковый персонаж, он весь код для макбуков пилит, можно сказать - ржавый титан класса император. Считай - линукс на макбуках всё.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Ядро это на 90% драйверы.

Последние замеры говорят, что лишь 24/40 == 60%.

Железячники тупые и Rust не осилят. Они и С осиливают весьма условно. Поэтому такой план не сработает.

А кому сейчас легко? Rust не от хорошей жизни появился.

zg
()
Последнее исправление: zg (всего исправлений: 1)

Прогресс не остановить. Дедушка старый - побурчит какое-то время, потом дуба даст, а пока можно и через FFI поработать.

Пролез же eBPF, пролезет и Rust со временем.

zabbal ★★★★★
()
Ответ на: комментарий от gaylord

Кажется лоровцы слишком ограничены чтобы вести дискуссию на эту тему, если даже тикет нагуглить не могут

Может для некоторых лоровцев новый диван поставить важнее, чем гуглить эту санта барбару? :)

pihter ★★★★★
()
Ответ на: комментарий от vbr

Ну как нет, вон Гектор Мартин уже хлопнул дверью, а это знаковый персонаж, он весь код для макбуков пилит, можно сказать - ржавый титан класса император.

Он та еще истеричка, я не удивлюсь если успокоится и отзовет.

Считай - линукс на макбуках всё.

Это катастрофизация. Там еще два мейнтейнера есть.

gaylord
()
Ответ на: комментарий от pihter

Может для некоторых лоровцев новый диван поставить важнее, чем гуглить эту санта барбару? :)

Тогда зачем писать на форум очевидный бред, если не знаешь, о чем говоришь?

gaylord
()
Ответ на: комментарий от alysnix

в системном софте проблема работы с памятью не стоит настолько остро как прикладном - в системщине аллокация на куче или любым нетривиальным аллокатором - это скорее исключение из правил. лучше такое вообще не допускать в силу больших вычислительных затрат и не вполне нормированном времени операции.

grep -R kzalloc linux-6.13.2 | wc -l что выдаёт?

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от gaylord

и ты их описал

Не, это так не работает. Зависимости д.б. где-то на meson.io уже описаны. А я просто их get. Ну или Rust/Go/Whatever. А описывать что-то – это нет. Ещё предложите ./configure запустить. Эти подходы давно устарели. И просто облегчают жизнь старпёрам. А объяснить молодым, зачем им для выполнения элементарного действия совершать непонятные движения, Вы никак не сможете. Они просто свалят и всё. На Раст свалят, например.

thegoldone ★★
()
Ответ на: комментарий от gaylord

Как разработчиков драйверов видео заботит что сетевики не хотят? Это вообще разные люди, никак не пересекающиеся.

Так получается не «в ядре поддержка rust» а «в драйверах видео поддержка rust». На протяжении всей этой движухи мне казалось что речь как раз о том что rust и C станут взаимозаменяемыми, можно будет одинаково писать как на одном, так и на другом, не ограничиваясь какими-то областями.

Там подобные драмы — обычный вторник

Ну я не слежу за тем что у них там происходит обычно, да. Просто когда из релиза в релиз ченджлог состоит из того что там какие-нибудь драйвера добавили и удалили, а тут внезапно вместо C можно писать на чем-то другом - мне было это интересно, даже как просто пользователю, мне кажется это значительное изменение.

micronekodesu ★★★
()
Ответ на: комментарий от zg

Куда именно его уходили? Он как был единственным владельцем торговой марки, так им всегда и оставался. На сколько я знаю не было ни одного релиза ядра без его одобрения. По крайней мере мажорного релиза.

https://www.zdnet.com/article/linus-torvalds-takes-a-break-from-linux/

Нет.

Ну не обязательно через три, может быть и через 5 и через 10. Торвальдсу сейчас 55 лет, сколько он ещё сможет тянуть этот проект и сколько ещё его когнитивные способности будут соответствовать лидеру проекта?

Всё ещё не вижу причин делать форк.

Вон Столлман, в своё время, замахнулся на целую операционную систему, но так и не смог довести её до ума.

Столлман вообще ничего до ума довести не смог. И как программист, и как руководитель он полное дно. Символично, что все успешные проекты GNU стали таковыми и начинали нормально развиваться как только RMS переставал мешать всем кто над ними работал. Даже Emacs без Столлмана стал только лучше, в нём наконец появился нормальный гуй (pgtk), поддержка treesitter и даже номера строк (да, раньше даже этого не было).

hateyoufeel ★★★★★
()
Ответ на: комментарий от alysnix

руст позиционировали куда-то в нишу голанга и прочих свифтов, то есть область прикладных задач с мусоросборкой.

Как раз нет. Rust изначально создавался как язык системного программирования. По крайней мере его первые публичные версии позицианировались именно так, несмотря на то, что язык зародился внутри проекта Mozilla. И мусоросборщика там нет. Ни такого как в Go, ни такого как в Java, .NET или Python. Даже близко нет.

zg
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.