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

Перлу 40 лет и он давно почти мертв, питону 35, и популярность только растет. В ближайшие десять лет никуда не денется.

За 10 лет столько всего может произойти. По-моему ты как-то совсем неосторожно вангуешь.

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

Этому ИИ будет без разницы, на чём программировать. Поэтому он сможет использовать более совершенный инструмент.

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

Пока что ИИ обучается на человеческом труде. И чем популярней язык, тем лучше он на нём пишет. Лучше всего на питоне. Не потому, что питон так уж подходит для ИИ, а потому, что на нём написано больше всего кода, по крайней мере доступного для публичного анализа.

Я не возьму на себя смелось предполагать фантастические вещи, про ИИ, изобретающий свой ЯП, идеальный именно для него, и начинающий писать на нём. Может быть такое и будет, ChatGPT 10 лет назад казался такой же фантастикой. Но я предпочитаю экстраполировать, чаще всего это работает. И вот экстраполируя можно предположить, что ИИ по прежнему лучше всего будет писать на тех языках, на которых больше всего написано кода. Поэтому мы можем взять, грубо говоря, топ-20 языков, по числу LoC на гитхабе, и выбирать среди них.

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

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

Включая меня. Но накативших Linux на новенький Макбук тут нет и вообще их чрезвычайно трудно найти, если вообще.

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

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

по этой причине на русте не будет написано ничего большого и серьезного. потому что большое и серьезное на хайпе не пишут.

Государство и крупный бизнес любят такое слово: безопасность. А значит при прочих равных инвестировать будут проекты на Rust, а не на Си. А также любят цифры и статистику, где многие CVE связаны с элементарными Сишными ошибками, которые в Rust невозможны в принципе.

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

Потому что винда как платформа более привлекательна, по причинам, о которых я писал. Сишка там внутри или Раст - десятое дело.

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

Я вас удивлю, а попробуйте поюзать git без perl.

Там существует тенденция по переписыванию перловки на Си. Просто Git создавался во времена, когда Перл ещё не окончательно оброс мхом и людьми поколения, в котором он был популярен. Со временем Перл из Гита выпилят окончательно. Надеюсь.

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

За 10 лет столько всего может произойти. По-моему ты как-то совсем неосторожно вангуешь.

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

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

Потому что винда как платформа более привлекательна, по причинам, о которых я писал. Сишка там внутри или Раст - десятое дело.

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

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

крупный бизнес любят такое слово: безопасность

Крупному бизнесу нужно в первую очередь выпустить продукт на рынок и получить прибыль. Безопасность всегда будет гражданином первого класса только в отдельных нишах типа спецслужб, банков и проч. Для всех остальных безопасность, грубо говоря, «будем чесаться, когда взломают».

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

А софтварный рейд, ЗФС в Линукс на расте написаны?

Автор bcachefs собирается портировать на Rust, да. Остальное было написано достаточно давно, чтобы там выбора ещё не было.

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

просто форкни ядро и переписывай. зачем тебе сидеть внутри чужого, живого, «ненадежного» кода?

Ну если старпёры в мейнтейнерах ядра и дальше в том же духе будут сопротивлться внедрению Rust, то может так и произойти. Только вот оригинальный Сишный Линуск может оказаться никому не нужен и бизнес откажется от инвестирования в него.

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

Так я тоже всё это против своей воли знаю

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

Лол в том, что реальная причина подменяется вымышленной «потому что мало раста».

Люди, которые нужны в Linux отличаются от людей, которые нужны корпорациям для написания очередного oneshot драйвера для bt свистка. Так понятнее?

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

Государство и крупный бизнес любят такое слово: безопасность. А значит при прочих равных инвестировать будут проекты на Rust, а не на Си.

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

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

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

А в винде кроме бт свистков больше ничего не используется?

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

Zig никак не помогает тебе защититься от порчи памяти

Порча памяти стартует в момент когда начинаешь учить Rust.

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

просто нет столько квалифицированных рустовых программеров

Бабло решает. Не было – появятся. За достаточное количество бабла даже на КОБОЛе квалифицированные программисты появляются.

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

GNU умер. Там не будет уже никакого тулинга.

Ещё шевелится и совсем без него нельзя. И ещё есть шанс, что там таки одумаются и перейдут на CMake.

У cmake ровно та же история. Версии старше какой-то двойки несовместимы назад. У make та же история. У всех такое, meson тут ничего не добавил.

Как давно это было у Make и CMake? А вот в Питоне это происходит постоянно, от релиза к релизу. Что нибудь да отвалится.

В его первой ипостаси он был всратый и неудобный. После появления meson они попробовали сделать получше, но уже поздно.

Почему поздно? Я думаю, что перевести проекты GNU на CMake будет куда как проще, чем на Meson. Даже чисто психологически, для GNU разработчиков.

В 80-х он был хорош. Сейчас уже нет.

А конкретнее?

Ну да, если у тебя старая версия cmake, проекты с новыми функциями я тебя не соберутся.

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

musl со сторонним аллокатором.

Почему там нет адекватного аллокатора и нужно тащить сторонний? Всё ли там хорошо с другими вещами, помимо аллокатора? Почему меинстримные дистрибутивы продолжают использовать glibc? Вот например моя Федора 41.

Потому что у меня нет gdb, а binutils это фактически часть gcc.

У тебя тулчейн LLVM? А операционная система какая или какой дистрибутив?

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

да ничего там не обмазано

Обмазано все: создание устройства открытия сокетов и файлов, запросы ФС, запросы в NVMe-oF устройства. Там счетчики просто везде.

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

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

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

Как давно это было у Make и CMake? А вот в Питоне это происходит постоянно, от релиза к релизу. Что нибудь да отвалится.

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

Почему поздно? Я думаю, что перевести проекты GNU на CMake будет куда как проще, чем на Meson. Даже чисто психологически, для GNU разработчиков.

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

А конкретнее?

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

Мы же обсуждаем совместимость в другую сторону. Если у меня что-то старое, я просто это обновлю.

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

Почему там нет адекватного аллокатора и нужно тащить сторонний? Всё ли там хорошо с другими вещами, помимо аллокатора? Почему меинстримные дистрибутивы продолжают использовать glibc? Вот например моя Федора 41.

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

У тебя тулчейн LLVM? А операционная система какая или какой дистрибутив?

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

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

Нет никакой сложности в самом бч. Он простой и тупой. Сложность заключается в том, чтобы удовлетворить бч, не обмазывая все в Arc<Mutex<RefCell<T>>> и не переписывая проект с нуля.

Я говорил ровно о том же.

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

Вообще да, не то чтобы много новых людей готовы с C страдать.

@seiken тебе хороший вопрос задал. Ведь под Винду драйверы на том же Си страдались, вот только там их почему-то больши и работают они там лучше. И мы все знаем почему - из-за большей популярности самой Винды.

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

это не те счетчики, что в русте считают ссылки на память. все эти линуховые счетчики придется в русте все равно реализовывать ручками, как в си.

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

@seiken тебе хороший вопрос задал. Ведь под Винду драйверы на том же Си страдались, вот только там их почему-то больши и работают они там лучше. И мы все знаем почему - из-за большей популярности самой Винды.

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

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

даже на КОБОЛе квалифицированные программисты

Но это другая ситуация. На COBOL есть куча легаси, которое надо поддерживать. С поиском работой проблем не будет.

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

Не. Ни у кого из уходящих не наблюдается организаторского таланта, какой был у Тео.

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

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

Тут важно не общее количество за всю историю, а количество в моменте. Сейчас в моменте может оказаться много. Впрочем мы всё увидим. Может быть ядро как нибудь разделится, на свобственно ядро и драйверную подсистему со всеми 60% кода драйверов.

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

это не те счетчики, что в русте считают ссылки на память

Это те же самые счетчики. Они делают то же самое – освобождают ресурсы, когда счетчик в ноль уходит.

все эти линуховые счетчики придется в русте все равно реализовывать ручками, как в си

И да, и нет. Тебе нужно будет сказать .clone(). Только вот в отличии от C, где люди регулярно продалбывают это, если ты не сказал, то у тебя код не соберется.

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

Они делают то же самое – освобождают ресурсы, когда счетчик в ноль уходит.

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

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

То есть для сборки минимальной системы, а это не только ядро, нужно ещё и Питон тащить в этот зоопарк с идиотским GNU Autotools.

Существует реализация языка сборки Meson на C99 под названием Muon. Это даже портативнее чем CMake.

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

изменения C API будут требовать правок биндингов или драйверы на Rust перестанут собираться

Ты не поверишь, но out-of-tree драйвер на си в этом случае тоже перестанет собираться и код будет требовать правок. Авторы сишных out-of-tree драйверов не жужжат и правят свои драйвера. Почему растофилы так не могут?

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

Так у растофилов же есть чудеснейший crates.io куда можно запузырить какой-нибудь linux_kernel_bindings который все писатели драйверов на расте будут использовать.

Забавно, когда нужно заниматься Rust Evangelism, то crates.io это огромное преимущество раста понад усе, решающее на корню все проблемы с лишней работой и источниками ошибок. А как до дела доходит, то про чудеснейшый crates.io никто не помнит и всем надо почему-то заново писать биндинги.

Да как так-то? :)

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

Под винду тебе нужен чувачелло, которы что-то напишет и как-то это возможно потом поддержит

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

seiken ★★★★★
()

Пусть в винду отправляют.

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

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

То, что он организовал разработку openbsd, openssh и ещё пачку проектов, тебя не смутило? Они не сами собой зародились, и чтобы вся эта армада аутистов, пихающих туда код, не пересрались друг с другом, нужен таки талант организатора. В впопенсорце очень не хватает способных менеджеров, которые могут вот такое вот. Код-то писать любой задрот может.

Может быть ядро как нибудь разделится, на свобственно ядро и драйверную подсистему со всеми 60% кода драйверов.

Для этого надо стабилизировать драйверный API. А этого никогда не случится, потому что Лойнус высрал stable-api-nonsense.txt и яростно придерживается. Т.е. пока Лойнус у руля, ядро будет монорепой.

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

Забавно, когда нужно заниматься Rust Evangelism, то crates.io это огромное преимущество раста понад усе, решающее на корню все проблемы с лишней работой и источниками ошибок. А как до дела доходит, то про чудеснейшый crates.io никто не помнит и всем надо почему-то заново писать биндинги.

Ты забыл тут про ЛГБТ написать.

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

Пока что ИИ обучается на человеческом труде. И чем популярней язык, тем лучше он на нём пишет. Лучше всего на питоне. Не потому, что питон так уж подходит для ИИ, а потому, что на нём написано больше всего кода, по крайней мере доступного для публичного анализа.

Да ИИ обучаются на людях и фактически являются экспертными системами на стероидах, то есть настоящего интеллекта в них ноль. Но вот про то, на чём лучше программирует ИИ я не думаю, что всё так однозначно. Он и на Go хорошо пишет, хотя Go до популярности Питона ещё далеко. То есть количество человеческого кода при обучении ИИ не играет такую уж критическую роль. Необходимо лишь, чтобы этого кода было достаточно - не меньше какого-то порогового минимума. И вот даже Go этот минимум перескачил. А Rust ещё менее популярен чем Go, но и на Rust ИИ тоже может вполно хорошо писать. Не на много хуже, чем на Питоне.

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

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

zg
()

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

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

Ты забыл тут про ЛГБТ написать.

А эта аналогия абсолютно неизбежна в дальнейшем, при честных ответах на задаваемые мной вопросы.

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

А эта аналогия абсолютно неизбежна в дальнейшем, при честных ответах на задаваемые мной вопросы.

Эта аналогия неизбежна, потому что в треде есть @Stanson, который не может не думать об ЛГБТ. Почти как Виталий Милонов!

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

Сишка в 2025 настолько бессмысленна, что это даже до Линуса уже дошло.

Он что-то говорил об этом прямо? Помню, что раньше (до короны, ИИ и обкуренного Маска), в одном из интервью, он таки очень хвалил Си в качестве системного языка программирования.

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