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

Ну наверное, но «меньше ядер – меньше работы» и «out-of-tree не работает говножопасотона» это довольно далекие друг от друга мысли :)

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

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

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

А дальше начинается вопросы: а они out-of-tree потому что разработка затруднена или потому что людям в общем-то нравится peer review, тестирование и возможность влиять на технические решения?

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

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

А дальше начинается вопросы: а они out-of-tree потому что разработка затруднена или потому что людям в общем-то нравится peer review, тестирование и возможность влиять на технические решения?

А это не важно уже, причин можно вагон найти: от лицензий (как у ZFS) до желания использовать средства, которые ядерщики к себе никогда не пустят типа C++.

Важно то, что Linux – единственная из трёх популярных ОС без стабильного ядерного API (и ABI). Иногда это обходят через дрова в юзерспейсе, отсюда мы имеем вагон разных демонов с libusb для поддержки разных клавиатур, RGB и прочего мелкого говна. Но чаще мы имеем залупу и необходимость таки самому писать драйвер.

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

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

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

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

А это не важно уже

Ну заход-то был что там ад и холост, а на деле может и нет.

Важно то, что Linux – единственная из трёх популярных ОС без стабильного ядерного API (и ABI). Иногда это обходят через дрова в юзерспейсе, отсюда мы имеем вагон разных демонов с libusb для поддержки разных клавиатур, RGB и прочего мелкого говна.

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

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

CMake разрабатывается коммерческой конторой KitWare.

Linux тоже разрабатывается коммерческими конторами. Никакого фо-фана уже давно нет даже близко.

Опять же есть готовый к использованию Muon, где ничего не надо кроме компилятора C99. Даже Make не надо.

Почему же он не взлетел? Если бы не эта тема, я врядли бы о нём услышал. А CMake даже в университетах преподают. Вот например здесь, на втором часу записи.

а вот совместимость с pkg-config, который также используется в Autotools – это большой плюс.

И он их готов брать без какой либо модификации прямо из под Autotools?

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

Это всё для виндузятников. Зачем это всё в Линуксе, когда есть apt, yum и т.п.?

Какое-то странное у тебя представление как о виндузятниках, так и о разработчиках. Ты пишешь программу А, которой нужна библиотека Б. Зачем тебе ставить библиотеку Б средствами dnf/yum/apt/etc. в свою систему, когда всё, что тебя интересует - слинковаться с этой библиотекой? Ну это как предлагать джавистам устанавливать jar файлы используемых библиотек, причём всех используемых версий одновременно, куда нибудь в /usr/lib вместо .m2 внутри домашней директории (в случае использования Maven). Вообще это совершенно порочная практика тянуть все develop зависимости именно как системные. Вот как раз чтобы так не делать и придумали conan и vcpkg. Кстати первый написан на любимом тобой Питоне.

Только у виндузятников. У разработчиков под Линукс и MacOS другое мнение.

Откуда ты это взял? Можешь дать ссылку на подобную дискуссию линукс разработчиков реальных проектов? Было бы интересно почитать.

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

И он их готов брать без какой либо модификации прямо из под Autotools?

Да.

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

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

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

Какое-то странное у тебя представление как о виндузятниках, так и о разработчиках. Ты пишешь программу А, которой нужна библиотека Б. Зачем тебе ставить библиотеку Б средствами dnf/yum/apt/etc. в свою систему, когда всё, что тебя интересует - слинковаться с этой библиотекой?

Опять же виндузятское мышление. В Линуксе для программы сделают пакет deb/rpm, который автоматически установит все зависимости.

Кстати первый написан на любимом тобой Питоне.

Это когда я его полюбил? Я положительно отношусь к Meson и отрицательно к Python.

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

Соборная модель, когда исходный код становится доступным с выходом каждого нового релиза программы, но во время работы над очередным релизом доступ к коду разрешён лишь ограниченному кругу разработчиков проекта. Как пример приводятся проекты GNU Emacs и GCC.

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

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

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

Потому что GCC перешёл к базарной модели разработки.

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

Опять же виндузятское мышление. В Линуксе для программы сделают пакет deb/rpm, который автоматически установит все зависимости.

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

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

Во время разработки используется devel пакет библиотеки, а в итоговом бинарнике runtime пакет библиотеки. Не вижу тут места для vcpkg/conan. Также в vcpkg/conan может быть версия библиотеки, не совместимая с версией дистрибутива.

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

Со своими фантазиями, что ли?

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

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

Но это усложняет жизнь тем, кто пишет на С основной код.

Нет.

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

Ты пишешь в ядро или у тебя тоже симпатическая тревожность?

gaylord
()

Ну, наконец-то! Наконец-то кризис как шанс понять, что пошли куда-то не туда...

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

Во время разработки используется devel пакет библиотеки, а в итоговом бинарнике runtime пакет библиотеки. Не вижу тут места для vcpkg/conan. Также в vcpkg/conan может быть версия библиотеки, не совместимая с версией дистрибутива.

Пакетные менеджеры для разработки софта и пакетный менеджер твоего Linux дистрибутива - это совершенно не одно и то же. vcpkg/conan, как и Maven/Gradle в Java, принесут тебе всё дерево зависимостей, а не только библиотеку Б. Твоя программа не должна зависеть от твоего дистрибутива, это совершенно порочная практика. Ты ведь именно поэтому устанавливаешь питоновские зависимости внутри venv, а не как системные.

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

Что код откомпилировался и запускается?

# cc -Wall -Wextra -Werror=return-local-addr 1.c -o 1
1.c:5:12: error: address of stack memory associated with local variable 'string' returned [-Werror,-Wreturn-stack-address]
    5 |     return string;
      |            ^~~~~~
1 error generated.
# cc -v
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Target: x86_64-unknown-freebsd14.2
iron ★★★★★
()
Последнее исправление: iron (всего исправлений: 1)
Ответ на: комментарий от zg

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

Нативная программа для дистрибутива Линукса должна.

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

Нативная программа для дистрибутива Линукса должна.

А у пользователя другой дистрибутив и другие версии ниже лежащих библиотек. Как ты, разработчик, проверишь/отладишь работу своей программы в таком окружении? Поставишь себе ещё один дистрибутив и так 100500 раз, под все дистрибутивы? Тебе, как разработчику, должно быть гораздо убоднее установить библиотеки где-то в домашней директории и линковаться с ними по мере необходимости. Автоматизацией именно этого и занимаются conan и vcpkg. Они нужны лишь разработчикам, а не конечным пользователям.

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

Это фундаментальная разница в подходе к софту у Linux и Windows. В Windows пользователь скачивает установщик из интернета, а в Линуксе устанавливает программу через пакетный менеджер дистрибутива.

Как ты, разработчик, проверишь/отладишь работу своей программы в таком окружении? Поставишь себе ещё один дистрибутив и так 100500 раз, под все дистрибутивы?

В Линуксах эту работу принято перекладывать на мейнтейнеров дистрибутивов.

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

И что твоя проверка показала? Что код откомпилировался и запускается? warning-и это не часть языка.

А в Rust часть языка? Можно увидеть его стандарт?

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

а жалкий тулкит

Какой ещё тулкит? Тулкиты на стороне клиента.

wayland(написанном на си)

Wayland вообще-то на XML написан. Про какой код Wayland на Си вы говорите? libwayland? Это просто библиотека реализации IPC, не более, никакой логики композитора там нет. И существуют версии этой библиотеки на Rust: https://github.com/Smithay/wayland-rs.

рисовать нескучные окошки.

Окошки в Wayland обычно клиент рисует. В GNOME Mutter серверные декорации вообще не поддерживаются.

X512 ★★★★★
()
Ответ на: комментарий от vbr
char *get_string(void) {
    char string[] = "hello";
    return string;
}

суть в том, что с точки зрения системщины этот код совершенно легален. просто тут возвращается указатель на первый символ string на стеке… ну напрмер чтобы распечать адрес на стеке этой переменной в образовательных целях (разъясняя студентам к примеру распределение памяти).

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

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

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

А драйверы под Винду тоже нужно переделывать из-за нестабильного API?

Ты не поверишь. Например, у меня валяется сканер Canon CanoScan 5000F для которого драйвера есть только под WinXP. Не переделали при очередном изменении API и вот.

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

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

Это давно решается системами сборики с пакетными менеджарами и нет, восе не с dnf/yum/apt, а с пакетными менеджерами для разработчиков. Например в Java для этого есть Maven и Gradle.

Если бы да кабы.

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

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

А там прямо такая сложная бизнес логика что без питонщины никуда?

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

Какое отношение использование гита ядром (на самом деле разрабами ядра) имеет к почти повсеместному засилию Гита? Вот скажи мне, какое джавистам или питонистам или дотнетчикам дело что там происходи в закрытой песочнице Торвальдса? И причём тут вообще GitHub? Разве не было точно такого же для Mercurial?

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

Окошки в Wayland обычно клиент рисует. В GNOME Mutter серверные декорации вообще не поддерживаются.

если честно, мне по барабану кто там и что рисует сам. :) пока не требовалось к изучению.

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

Ты не поверишь. Например, у меня валяется сканер Canon CanoScan 5000F для которого драйвера есть только под WinXP. Не переделали при очередном изменении API и вот.

Скорее всего там просто версия винды прошита где-то в inf файле и если поменять, то заработает. Но железка слишком старая, чтобы кто-то из Canon этим озаботился.

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

Скорее всего там просто версия винды прошита где-то в inf файле и если поменять, то заработает.

Нет, не заработает. Оно и без всяких правок установится вплоть до дрисняточки, но винды после WinXP будут падать в BSOD.

Но железка слишком старая, чтобы кто-то из Canon этим озаботился.

Ну да, разумеется они не хотят за изменениями API в венде следить, они хотят новые железки продавать.

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

Это фундаментальная разница в подходе к софту у Linux и Windows. В Windows пользователь скачивает установщик из интернета, а в Линуксе устанавливает программу через пакетный менеджер дистрибутива.

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

В Линуксах эту работу принято перекладывать на мейнтейнеров дистрибутивов.

Это совершенно порочная практика, которой быть не должно в принципе. Она существует благодаря фрагментации платформы Linux и она же порождает ещё большую её фрагментацию.

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

Это совершенно порочная практика, которой быть не должно в принципе. Она существует благодаря фрагментации платформы Linux и она же порождает ещё большую её фрагментацию.

Ну значит вы виндузятник, враг Линукса и свободы. По крайней мере по мнению GNU сообщества и авторов основных дистрибутивов.

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

В Линуксах эту работу принято перекладывать на мейнтейнеров дистрибутивов.

В итоге появились Appimage, Snap, Flatpak. И все бросились писать приложения на Electron, ибо надоело вместо разработки приложения заниматься всякой хернёй.

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

Уже второй. Ваш класс с уроков пораньше отпустили что-ли? Ну берите домашнее задание - переписать пример так, чтобы clang не выдавал предупреждений.

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

В итоге появились Appimage, Snap, Flatpak.

Это всё по сути отдельные дистрибутивы со всеми вытекающими.

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

Ты не поверишь. Например, у меня валяется сканер Canon CanoScan 5000F для которого драйвера есть только под WinXP.

Поискал драйвер для твоего сканера. Нашёл на официальном сайте драйвер, одновременно и для XP и для Vista и для 2000. Разве между этими версиями Винды API драйверов не менялся?

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

Это фундаментальная разница в подходе к софту у Linux и Windows. В Windows пользователь скачивает установщик из интернета, а в Линуксе устанавливает программу через пакетный менеджер дистрибутива.

Не напомните, какой официальный и единственно рекомендуемый способ установки rust в linux?

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

Ну значит вы виндузятник, враг Линукса и свободы. По крайней мере по мнению GNU сообщества и авторов основных дистрибутивов.

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

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

Это давно решается системами сборики с пакетными менеджарами

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

Ну вот Перл сдох и я этому безмерно рад.

Вот только его популярность заметно снижалась на фоне питона, а у последнего она только растет.

А там прямо такая сложная бизнес логика что без питонщины никуда?

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

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

Какое отношение использование гита ядром (на самом деле разрабами ядра) имеет к почти повсеместному засилию Гита?

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

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

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

Лично я этого мнения не придерживаюсь и умным его не считаю. Но в Линус экосистеме оно устоявшееся. Вряд-ли Линукс дистрибутивы с традиционными пакетными менеджерами, пакующими всякую мелочь вроде libpng, куда-то денутся. Snap/FlatPak продвигаются с трудом.

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

Не напомните, какой официальный и единственно рекомендуемый способ установки rust в linux?

Официальный у кого? У авторов Rust – curl https://sh.rustup.rs -sSf | sh. У авторов дистрибутивов – пакет rust в местном пакетном менеджере. Тут есть конфликт интересов.

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

Разве между этими версиями Винды API драйверов не менялся?

Судя по всему, те элементы API которые нужны для этого драйвера - не менялись. А потом поменялись и опа.

Из перечисленного, кстати, выбор для установки в виртуалочку, очевидно, WinXP. У меня где-то даже qcow2 c WinXP валяется для этого дела, хоть сканер и не требовался уже несколько лет.

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