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)

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

Вполне здравая мысль. Если практически каждую структуру обвязывать(по сути дублировать) и по сути требовать сопровождения, то такие действия и патчи не нужны.
В чужой дом - не лезут со своими правилами.
Пусть тогда дорабатывают компилятор, чтобы использовал структуры языка «C».

Atlant ★★★★★
()

Пусть Zig лучше в ядро принимают, он-то умеет контачить с C API напрямую и слой безопасности для ментейнинга там на порядок тоньше.
Сам примерно по той же причине свичнулся с Rust на Zig в прошлом году.

Пусть принимают

Когда язык достигнет версии 1.0, разумеется.

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

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

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

Пусть Zig лучше в ядро принимают

Пусть не принимают, по той же причине.

ставят сопровождающих в зависимость от кода на языке Zig

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

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

А разговоров-то было…

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

Пусть тогда дорабатывают компилятор, чтобы использовал структуры языка «C».

С прогрессиыными современными технологиями (тм) это так не работает

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

pihter ★★★★★
()

Последствия внедрения без чёткого понимания цели и необходимости внедрения.

Создаётся впечатление, что в сообществе раста часто есть такая проблема: не важно, зачем, лишь бы на расте.

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

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

Это не так. Абстракции гарантируют некоторый контракт, который в C гарантируется исключительно тестированием, страданием и багрепортами.

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

Пусть Zig лучше в ядро принимают, он-то умеет контачить с C API напрямую и слой безопасности для ментейнинга там на порядок тоньше.

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

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

нафиг он не нужен в ядре

Чтобы ядерные программисты меньше страдали.

кто в этом потом разбираться будет

Программисты.

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

Страдать с сишными багами не менее трудозатратная работа.

gaylord
()

Ничего не понял, но кажется это не кризис а чёткое разграничение где должен заканчиаться С и начинаться Раст.

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

Ничего не понял, но кажется это не кризис а чёткое разграничение где должен заканчиаться С и начинаться Раст.

Мейнтейнер не хочет Rust в своей подсистеме, в его подсистему никто патчей-то и не предлагал. Другое дело что Hector Martin устроил истерику и пошел собирать своих друзяшек в крестовый поход, за что ему справедливо напихали в панамку.

gaylord
()

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

drl
()

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

Основная проблема. Стабильного API нет, и его введение необходимое для раста может парализовать разработку ядра.

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

Создаётся впечатление, что в сообществе раста часто есть такая проблема: не важно, зачем, лишь бы на расте.

На третий день Зоркий Глаз заметил, что стены нет

buddhist ★★★★★
()

Некто Hector Martin залупнулся, что Christoph Hellwig нарушил КоК, и начал поливать его грязью в своем мастодрочике. На что Линус сказал, что так дела не делаются. Hector Martin пересрался, стёр свой пост и решил на всех обидиться. Продолжение драмы смотрите в следующей серии!

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

Да не, это я как раз понял. Я про всю эту разницу между инерфейсами, обвязками и вызовами. Да мне в принципе и не надо.

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

Кристоф Хелвиг <...> отказался подтверждать патчи

А какая там вообще организация? Кто-то может стукнуть по столу и заставить его принять эти патчи? На сколько сложно его выгнать и взять того кто это примет? А когда Раст в ядро внедряли там не было договоренности на сколько глубоко будут внедрять, а то может это реально команда с растом виновата? Короч жду чтоб Финский рассказал кто там из сторон конфликта в этот раз является сборищем тролей-коммунистов.

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

Судя по всему право окончательного стука по столу у Линуса. А у Кристофа - относительно его направления.

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

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

там, вроде, проверка границ массивов встроена по дефолту, что уже нефиговый шаг по сравнению с сишечкой- плюсишечкой, но до раста всё это конечно не дотягивает

а его метапрограммирование хуже, чем у C

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

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

А какая там вообще организация? Кто-то может стукнуть по столу и заставить его принять эти патчи?

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

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

там, вроде, проверка границ массивов встроена по дефолту, что уже нефиговый шаг по сравнению с сишечкой- плюсишечкой, но до раста всё это конечно не дотягивает

Простые кейсы покрыты (запись в массив на стеке известной длины), но они и в C уже покрыты с помощью stack protector. А все остальное сегфолтится не хуже сишки. UAF, NULL pointer deref, это все там стреляет на ура.

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

В сишке есть препроцессор с помощью которого можно делать чудовищной красоты костыли.

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

А когда Раст в ядро внедряли там не было договоренности на сколько глубоко будут внедрять, а то может это реально команда с растом виновата?

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

gaylord
()

Если всё, что написанно на расте в ядре выкинуть, ядро останется работоспособным?

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

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

Нет, они дорабатывали тулчейн под требования ядра. Есть даже трекинг: https://github.com/Rust-for-Linux/linux/issues/2

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

gaylord
()

им следует делать это в своём драйвере, а не распылять эту «раковою опухоль» на основное ядро

Удваиваю это.

no-such-file ★★★★★
()

Rust - write-only блевотина.

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

Удваиваю это.

Проблема в том, что это довольно базовая абстракция для работы с DMA. И люди утащили её в rust/kernel/dma, где сами и будут её мейнтейнить. Для dma подсистемы это по сути ещё один потребитель, а не её часть.

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

Человек явно тролит.

В Зиге стреляет в те моменты, когда в Си не стреляет.

Да и метапрограммирование. Сказать, что препроцессор в Си лучше комптайма — не понимать сути комптайма.

На днях один блогер пожаловался, что в Зиге комптайм есть, а концептов как в Расте нету. Что нельзя наложить ограничение. Я посмотрел и сделал рука-лицо. Человек привык к концептам и не смог догадаться написать функцию isTypeAlike(T1, T2).

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

Человек явно тролит.

Нет.

В Зиге стреляет в те моменты, когда в Си не стреляет.

В зиге стреляет чуть больше, все так. Но zig даже близко не подходит к тому что предлагает rust, поэтому замена не выглядит адекватной.

Да и метапрограммирование. Сказать, что препроцессор в Си лучше комптайма — не понимать сути комптайма.

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

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

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

Погоди. Ты написал «его метапрограммирование хуже, чем у C». Это не так.

Макросы в ядре меня никогда не интересовали. Я сталкивался с макросами в OpenSSL. Это было конечно круто, но по сути два кейса: сделать контейнеры для ASN1-массивов, и сделать рефлексию собственно ASN1. Зиг это реализует без трэша.

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

Страдать с сишными багами не менее трудозатратная работа.

да, но от этого не уйти. Никто же не предлагает переписать все ядро на расте.

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

Погоди. Ты написал «его метапрограммирование хуже, чем у C». Это не так.

Мы же говорим в контексте ядра. Собственно и Rust снаружи вполне себе годный был, а когда потащили внутрь, выяснилось что через слово вылезают проблемы. Я так понимаю что pinned places появились в том числе как ответ на вопрос «господи что это за срань с pin projection у вас для intrusive lists».

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

да, но от этого не уйти. Никто же не предлагает переписать все ядро на расте.

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

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

Типичная стратегия растовиков - что-то не получается - иди орать в мастодон, какие все мудаки и надо их набутылить

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

Предлагается провести эксперимент и начать писать хотя бы новые драйверы

Кто ж им мешает? Пусть запилят альтернативную реализацию какого-нибудь модуля.

люди утащили её в rust/kernel/dma, где сами и будут её мейнтейнить

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

no-such-file ★★★★★
()

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

Обязательно хочешь писать ядро - напиши своё. По примеру musl. Не можешь с нуля - возьми существующее и перепиши его полностью на ржавом. И будет своё отдельное ржавое ведро. Зачем лезть туда, где тебя не ждут и не жалуют рискуя порушить то, что строилось много лет?

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

Обязательно хочешь писать ядро - напиши своё.

Так Redox уже есть и развивается. Нужно туда патчи на C отправить, пусть принимают. :)

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

Да вы, батенька, Фима Шифрин прям.

Я в этом самом сообществе не варюсь круглосуточно, поэтому да, впечатление приходит со временем.

apt_install_lrzsz ★★★
()

Все правильно. Просто представить ситуацию: чувак написал код на Си, который ломает раст-биндинги.

Ему пообещали, что с этим будут разбираться специальные дружелюбные раст-мейнтейнеры.

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

Чего с этим делать? В теории возможно только 2 варианта: либо заставить всех кодить на расте, либо послать раст нафиг с пляжа. Специальные дружелюбные раст-мейнтейнеры естественно рассчитывали на первый, но похоже их вовремя вывели на чистую воду.

Lrrr ★★★★★
()

Кажется, что линукс пора форкать, оставляя Торвальдса на задворках истории, точно так же как это произошло ранее с XFree86.

MEZON ★★★★★
()

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

а то им сразу коммиты подавай.

alysnix ★★★
()

По-моему это кризис поколений. Поколение Линуса и тем более Столлмана - это поколение Си, экзотических терминалов, Emacs и говноутилит вроде GNU Autotools. Новое поколение так жить не хочет, отсюда и Rust с его Cargo и прочая модно-молодёжная движуха в IT. Ситуация напоминает оную с Xorg и Wayland.

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

новому поколению инклузивных зуммеров никто не мешает запилить свою ОС, а не лезть в чужую.

а то ситуация похожа на захват жизненного пространства, сами знаете кем. места мало что-ли?

alysnix ★★★
()

Это тот очередной случай, когда отсутствие стабильного API для драйверов оборачивается жопой. Когда-нибудь люнексоеды дойдут до идеи, что API можно не менять несколько лет и, возможно, даже версионировать! Но не сегодня.

hateyoufeel ★★★★★
()

раковою опухоль

Крабовую

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