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)
Ответ на: комментарий от alysnix

а ваше владение со счетчиками ссылок системщине не надоть

В Линуксе полно объектов со счётчиком ссылок. Поищите по исходкикам структуру kref.

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

постепенное переписывание компонентов ялра на Rust сразу приведёт к положительным изменениям и это менее трудозатратно.

Форкни и переписывай как угодно, хочешь постепенно, хочешь сразу. Никто не мешает.

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

Ну дык там всё в бете. Это как линукс в 93-м году. Со временем стабилизируется, если желание не пропадёт у разработчиков и ничем не будет отличаться от новенького синкпада, а то и лучше будет.

Ну то есть это pet project и это несерьёзно и мало кому интересно.

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

я не думаю, что всё так однозначно

Нет, тут все однозначно. ИИ делает так как в обучающем материале, и точка. От качества обучающего материала и от его количества зависит очень много. Так устроен ИИ.

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

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

Язык сборки Meson – это полностью отдельный и независимый язык. Он не является каким-либо подмножеством Питона.

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

Разве ИИ прогоняет свой код через компилятор? Совсем нет и на практике его код довольно часто просто не компилируется. Хотя если бы прогонял, мог бы сам себя исправлять, но это требует дополнительных ресурсов и вовсе не GPU-шных.

Я про автономную работу. Конечно там будет компиляция и итерации.

И, да, агенты уже есть. Вот vscode на днях зарелизили своего агента. Делает правки кода, прогоняет компиляцию, смотрит на выхлоп и фиксит и тд.

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

Ну то есть это pet project и это несерьёзно и мало кому интересно.

Я весь десктопный линукс так воспринимаю.

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

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

Boson уже больше года не обновлялся уже не актуален. На смену ему пришёл Muon который вполне юзабелен.

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

Потому что в этом вашем ядре из-за дырявой Сишки регулярно находят критические уязвимости

Тек более есть прямой смысл не трогать существующее ядро на дырявой сишке. Оставьте дырявое ядро как пример ужасного кода и напишите распрекрасно-безопасный код на расте. И будете наглядно демонстрировать преимущество раста противопоставляя дырявое сишное ядро и блестящее супер-безопасное растовое ядро. Это ж какой бомбический эффект будет в пользу раста!

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

В Линуксе полно объектов со счётчиком ссылок.

уж обсудили.

счетчики ссылок в механизме некоей автоматической сборки мусора(как в мусоросборочных язвках, русте и смартпоинтерах с++) и счетчики ссылок в отслеживании использования - разные вещи.

первые поддерживаются компилятором и считают копирование ссылки на обьект. вторые - чисто ручной код типа inc_ref/dec_ref. это никак компилятором не поддерживается.

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

Открою страшную тайну, что современное высокопроизодительное железо тоже делают программисты на специальных языках программирования вроде HDL или Verilog. Времена когда компьютер можно было сделать с помощью паяльника и TTL микросхем давно прошли.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от alysnix

и счетчики ссылок в отслеживании использования - разные вещи.

Это с чего вдруг? В машинных кодах это абсолютно одно и тоже.

это никак компилятором не поддерживается.

В том и вся суть Rust, что он не даст вам забыть написать inc_ref/dec_ref так чтобы у вас память потекла или случилось use after free.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от liksys

Это самосбывающееся пророчество. На питоне уже написано огромное количество кода, и создается новый. Его активно допиливают, избавляясь от GIL и добавляя модные фичи. Плюс, им активно пользуются в научных вычислениях и ML. А если использовать питон сейчас для тех же сборочных систем (что уже происходит), то это еще больше продлит его жизнь.

У Перла было всё то же самое, кроме разве что научных вычислений и ML и тем не менее Перл умер. Просто пришло новое поколение, для которого типичная перловка оказалась дикостью и они проголосовали ногами. У Питона тоже есть набор застарелых проблем, которые так же могут когда-то выстрелить. Например отсутствие аналога джавовского classpath, что приводит к необходимости городить venv и скачивать зависимости туда для каждого проекта заново. Синтаксис, основанный на отступах так же далеко не всем нравится и может перестать нравиться ещё большему числу разработчиков в будущем. Кроме того Питон динамически типизированный и многие ошибки типизации проявляются лишь в рантайме и далеко не всегда сразу. type hints - попытка замести проблему под ковёр. У Питона долгое время принципиально не было JIT, что очень больно било по его производительности. Сейчас JIT вроде бы завезли, но лишь эксперементальный. Короче Питон - это такой скриптоязык, напоминающий недоделанную Джаву с кучей синтаксического сахара. Сейчас всё это многих устраивает, как когда-то устраивал Перл, но со временем всё может измениться.

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

Открою страшную тайну

ну вот потрясающая тайна…я вот много лет назад писал лексер для VHDL, группе что делала VHDL компилятор.

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

В том и вся суть Rust, что он не даст вам забыть написать inc_ref/dec_ref так чтобы у вас память потекла или случилось use after free.

это фантазии.

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

Крупному бизнесу нужно в первую очередь выпустить продукт на рынок и получить прибыль

Поддерживаю этого оратора. Всем нормальным людям глубоко насрать на «безопасность» и корректность кода. Пусть оно течёт как сучка и падает через раз, но если за успешный запуск бизнес получает X долларов, а в случае падения выплачивает X/10 компенсации, то продукт считается успешным. И зарабатывает деньги пока растоманы пытаются доказать компилятору великую теорему Ферма на контрактах и БЧ.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от alysnix

каким образом будет изменяться значение такого счетчика? явно(вызовом неких функций inc_usage/dec_usage) или неявно?

Неявно.

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

Ну конечно, ведь Линукс - это или-и-и-ита, и только в нём грамотно построен процесс разработки.

Жирно же, ну. Очевидно что опенсурсный мейнтейнер и дядька в офисе на зарплате это два разных человека с двумя разными наборами скилов.

А в MS берут только лузеров, которых не пустили в Линукс.

MS тут вообще не при чем. MS не пишет драйверы для сторонних устройств.

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

То, что человек неизбежно совершает ошибки на каждое n-ное количество строк кода каким бы профессионалом он ее был – это неотвратимая объективная реальность. И Rust позволяет избежать многие такие ошибки.

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

Язык сборки Meson – это полностью отдельный и независимый язык. Он не является каким-либо подмножеством Питона.

Является. Просто не тьюринг-полным. А так там очень похожее конструкции.

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

Например отсутствие аналога джавовского classpath, что приводит к необходимости городить venv и скачивать зависимости туда для каждого проекта заново.

Это уже малоактуально в эпоху докеров.

Синтаксис, основанный на отступах

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

type hints - попытка замести проблему под ковёр

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

Сейчас JIT вроде бы завезли, но лишь эксперементальный.

Не лишь, а вполне неплохо. Это показатель того, что язык активно развивается.

liksys ★★★★
()
Ответ на: комментарий от no-such-file

Всем нормальным людям глубоко насрать на «безопасность» и корректность кода.

Напомнить что про BSOD писались целые баллады? Вот настолько всем было «насрать» на то что windows упала посреди работы и потеряла последний час твоих умственных трудов.

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

И Rust позволяет избежать многие такие ошибки

Не позволяет. Раст не даёт «ошибочному» коду скомпиляться. Сами по себе ошибки никуда не деваются.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от X512

В языке Meson не используется табуляция для указания вложенных конструкций как в Питоне.

Так их и питон не использует. Там четыре пробела стандартный стиль.

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

Вот настолько всем было «насрать» на то что windows упала посреди работы и потеряла последний час твоих умственных трудов

Статистика использования ОС подтверждает, что всем таки насрать. И на БСОД тоже.

no-such-file ★★★★★
()
Ответ на: комментарий от X512

И Rust позволяет избежать многие такие ошибки.

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

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

Да боже мой, причем тут питон? У тебя в дистрибутиве есть некоторая версия meson. Ей соответветствует некоторая версия Python. За этим следят разработчики дистрибутива. Все, проблемы нет.

То есть перейти на более новый Meson я не смогу, потому что у меня всё прибито гвоздями. Хотя обычно я могу установить ещё одну версию Питона, а значит и другую версию Meson… Хотя снова не всегда, ведь собирать я могу из сорсного пакета, где опять же всё прибито гвоздями. То есть да, если захотеть, можно и накатить и собрать. Вот только зачем этот зоопарк версий разводить?

Не знаю, я не знаю живых разработчиков GNU.

Общался с одиним по переписке. Ощущения как от общения с пенсионером.

Я не пойду в Make-срач, извини. Это будет очень утомительно.

Я не ради срача спросил, мне просто стало интересно.

Никуда ты ничего не обновишь на RHEL или Astra Linux.

Разве там вообще есть необходимость обновлять CMake? По-моему он там и так достаточно новый. По крайней мере в RHEL.

Потому что так вышло.

Ну вот не удивляйся, когда Питон начнёт движение в гости к Перлу.

У меня рач, я просто не пользуюсь gdb.

Что за рач? Arch что ли?

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

И Rust позволяет избежать многие такие ошибки.

И типа количество ошибок будет меньше. Теоретически правильно. Правда, исключительно исходя из ничем не обоснованного предположения, что профессионализм пишущих на расте равен профессионализму пишущих на сишке.

Практически же, профессионалов пишущих на расте нет. На расте пишут нубы обработанные Rust Evangelism Task Force. Поэтому на расте нет ни единого оригинального проекта, а неоригинальные проекты ничего кроме смеха и презрения из-за обилия нубских ошибок не вызывают.

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

Потому что драйверы на Rust in-tree, а значит их нельзя ломать.

Зачем и кому нужно чтобы они были in-tree? Особенно если учесть что in-tree драйверы на расте приводят к куче проблем в ядре, а out-of-tree драйверы на расте никаких проблем не создают.

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

Зачем и кому нужно чтобы они были in-tree? Особенно если учесть что in-tree драйверы на расте приводят к куче проблем в ядре, а out-of-tree драйверы на расте никаких проблем не создают.

Линусу, потому что он хочет второй язык.

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

Линусу. Потому что это его политика не поддерживать out-of-tree драйвера.

Все правильно, зачем ему поддерживать драйвера? Он что производитель железа?

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

не… ну это слишком логично и просто звучит, наверняка массонская ложа с иллюминатами подсуетились

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

Это несколько параллельные реальности. Под винду тебе нужен чувачелло, которы что-то напишет и как-то это возможно потом поддержит. А возможно и нет (поищи сколько страданий «обожемоймоежелезоопятьсдохло» когда очередную винду на свалку отправляют). В Linux тебе нужен мотивированный дядя, который патчи будет отсматривать, комментарии по делу давать и как-то продвигать инженерную мысль вперед. Это вообще другие люди.

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

zg
()
Последнее исправление: zg (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Статистика использования ОС подтверждает, что всем таки насрать. И на БСОД тоже.

Это вообще не связаные вещи.

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

Потому что это его политика не поддерживать out-of-tree драйвера.

И что? Пусть не поддерживает. Растоманы же себя пяткой в грудь колотят что они всё сами будут поддерживать. Вот и флаг им в руки.

no-such-file ★★★★★
()
Ответ на: комментарий от zg

В реальности у тебя в ядре Linux есть опенсурсные мейнтейнеры, которые координируют работы, в ядре Windows – нет. Ты это оспаривать собрался? :)

gaylord
()
Ответ на: комментарий от no-such-file

Растоманы же себя пяткой в грудь колотят что они всё сами будут поддерживать. Вот и флаг им в руки.

Ну они и поддерживают в рамках репозитария Linux.

hateyoufeel ★★★★★
()
Ответ на: комментарий от no-such-file

Интересно будет все таки ответ на мой вопрос про nvidia, или правда никто этого не знает :(

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

вопрос ко всем раставчанам.

в расте можно разделить декларации и имплементацию на разные файлы?

например из модуля M1, надо экспортировать функцию my_fun(). это должно описываться в отдельном файле, чтобы не показывать весь файл реализации с наивными эти пабликами.

alysnix ★★★
()
Ответ на: комментарий от no-such-file

И что? Пусть не поддерживает. Растоманы же себя пяткой в грудь колотят что они всё сами будут поддерживать. Вот и флаг им в руки.

Так это буквально то, как R4L разрабатывался. А теперь это все в mainline несут, потому что так хочет Линус.

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

Да не важно какая какие отступы, символом таба или пробелами. В языке Meson никакой нет. Там что-то по типу Паскаля: if/endif, foreach/endforeach.

X512 ★★★★★
()
Ответ на: комментарий от no-such-file

А в других репозирариях им религия не позволяет? Из-за чего весь сыр-бор?

Они уже это делают, прямо сейчас.

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

Да не важно какая какие отступы, символом таба или пробелами. В языке Meson никакой нет. Там что-то по типу Паскаля: if/endif, foreach/endforeach.

А, это. Да, здесь оно другое.

gaylord
()
Ответ на: комментарий от no-such-file

Какой-то странный довод. Код, который не компилируется – это и не код вовсе. Он не пройдёт CI.

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

не поверишь но да, оказывается, бывают системные языки с развитой модульной системой, и раст один из них

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

Мы вам благо принесли, а то что вам теперь стало неудобно - ваши проблемы, мы ж прогрессивно принесли

Щас им маятник, солнышко сделав, с обратной стороны втащит, так что мало не покажется:) «ретроградские деды» именно поэтому смелеют — щас еще про ненужность CoCа отдельный срач в LKML будет.

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