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

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

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

А манной небесной он и вправду не является. И во все щели его засунуть не получится. К попыткам засунуть его в линукс я лично отношусь скептически.

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

Greg KH может и ты можешь.

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

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

Я говорю о настоящей реальности и привёл конкретный пример программы, которую до недавних пор в Федоре принципиально не обновляли, кроме как ради релиза новой версии самого дистрибутива.

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

Ниша раста - это замена C++.

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

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

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

Tauri против Electron?

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

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

Flash Player, например, сдох. Вероятно из-за неимоверного количества дыр. Переписали на расте.

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

Какое мне до него дело?

Он справляется, а ты нет. Он управляет Linux Kernel (крупнейшим опенсурсным проектом на планете), а ты в офисе пердолишься. При этом ему за 50. Так что сорян, skill issue. Git gut.

Я говорю о настоящей реальности и привёл конкретный пример программы, которую до недавних пор в Федоре принципиально не обновляли, кроме как ради релиза новой версии самого дистрибутива.

Зачем пользоваться Fedora?

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

Tauri против Electron?

это имеет какое-то отношение к С++? ну или имело?

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

В zig есть пакетный менеджер

Это не пакетный менеджер а посмешище. У настоящей экосистемы есть пакет leftpad, у node.js есть, у Rust есть. А у zig нету.

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

Flash Player, например, сдох.

оценочное суждение.

Вероятно из-за неимоверного количества дыр.

сомнительное предположение

Переписали на расте.

факт(если таковой случился), сам по себе ничего не значащий. переписали и что? могли и на брейнфак переписать.

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

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

«Не осилили» или есть ограничения принципиального характера?

Оно выглядит таким же страшным как в Rust и плохо вписывается в язык, так же, как в Rust.

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

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

«Hello world!»?.. ;)

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

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

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

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

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

В JavaScript нету потоков, в С++ co_await строит конченный автомат если правильно понял.

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

Асинхронность можно (нужно?) применять вместе с многопоточностью. Это разные вещи.

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

оценочное суждение

Поддержка прекращена. Из браузеров удалён.

сомнительное предположение

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash

переписали и что?

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

Тупик: Adobe Flash Player сдох, но swf файлики остались.

факт(если таковой случился), сам по себе ничего не значащий.

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

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

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

Заблуждение. В дело включится [не]явный event loop, которого нет в приложениях с простым использованием потоков и нитей.

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

Я думаю надо начать с реформы человеческого языка. Языков. Всех.

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

поэтому в финале СИ победит РАСТ

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

В JavaScript нету потоков, в С++ co_await строит конченный автомат если правильно понял.

«конченный» в смысле херово реализованный? Просто оно там не так уж и плохо реализовано если не лезть в кишки и пользоваться обертками/библиотеками.

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

В дело включится [не]явный event loop, которого нет в приложениях с простым использованием потоков и нитей.

зачем языку системного уровня «неявный» event-loop, когда его легко написать явно. в три примерно строки?

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

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

зачем языку системного уровня «неявный» event-loop, когда его легко написать явно. в три примерно строки?

Эндрю Келли так и сказал: коллбэки в зиге уютные, а с async/await получается мрак.

Если следить за теоретиками, то каждый await делит процедуру на две половины, и стейт надо сохранять в хипе. Языкам с GC такой способ подходит лучше.

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

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

LMAO ты ядра что ли не видел? Там schedule_work через queue_work_on.

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

зачем языку системного уровня «неявный» event-loop, когда его легко написать явно. в три примерно строки?

Ну сначала в три строки, а как приложение вырастет это будет switch case на тысячи строк. А уж изменять последовательность работы в таком!

Попробуй мысленно развернуть какой нибудь async/await код.

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

и стейт надо сохранять в хипе

Можно посчитать размер будущего стека и выделить на стеке родителя. Или заранее буфер передать, выделив через my_malloc(sizeof_stack(fn)).

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

Можно посчитать размер будущего стека

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

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

выделив через my_malloc(sizeof_stack(fn)).

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

В прошлом году замечал, что безотносительно языков формируется мнение, что async/await не оч.

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

Ну а в чем проблема? Хоть гигабайт ложи, компьютеру тяжелее от величины числа не станет. Про хватит или не хватит места под стек это уже другой вопрос, не относящийся к async/await.

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

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

А чем он так хорош/лучше прочих? Не флуда ради, я «не в теме» просто...

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

неявный контрол флоу, неявный ивентлуп, неявные выделения памяти

Верно только первое, однако ничего хорошего в многометровом switch case не вижу, сохранение лямбд ничем не лучше.

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

Самое смешное, что он ничем не хорош и ничем не лучше. Это второй D, который пытается сделать всё немного лучше, но без кардинальных изменений людям это не надо.

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

Ну а в чем проблема?

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

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

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

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

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

А чем он так хорош/лучше прочих? Не флуда ради, я «не в теме» просто…

Во-первых, зиг еще не готов для продакшена. Постоянно что-то ломают в языке и стд.

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

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

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

асинк функция - это корутина. а await - это проверка некоего условия и если оно не выполнено - вызов корутинового yield - то есть переключение контекста на другую корутину.

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

а когда все стало ого-го как продвинуто! корутины обозвали асинк функциям, а yield спрятали в await.

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

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

чегоо? у тебя компилятор видит только заголовок функции void f();

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

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

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

Бред какой то, было у тебя fileReadSync, стало await fileReadAsync(), эффекта ноль, выполнение идет в таком же порядке, прироста ноль.

асинк функция - это корутина. а await - это проверка некоего условия и если оно не выполнено - вызов корутинового yield - то есть переключение контекста на другую корутину.

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

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

чегоо? у тебя компилятор видит только заголовок функции void f();
он написан в каком-то хидере или файле экспорта или еще где. тела ее(в общем случае) он не видит в принципе

Ну значит в ограничение в случае с С++ добавляем обязательную реализацию в хедере.

+ Вызов async функций может происходить только из async функций.

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

Я пользуюсь только zig c / zig cc

Да, это важный момент — удобная замена компилятору. Скажем, под виндовз можно не качать mingw, не качать вижуалстудию. Можно С/C++ программу компиллировать зигом, который достать сильно проще, буквально pip install zig. И результирующий ехе будет без зависимостей от MSVC-рантаймов.

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

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

Нет это для тех кто не хочет размазывать одну функцию на десяток функций.

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

В идеале совмещаешь многопоточность и асинхронность, достигаешь максимальной производительности.

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

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

Зеленые потоки менее производительны, если раскрашивать функции async то компилятор сможет оптимизировать в switch/case который вручную пишут сишники.

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

Ну значит в ограничение в случае с С++ добавляем обязательную реализацию в хедере.

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

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

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

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

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

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

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

Да я бы был рад, если бы она была не нужна. Ещё бы разработчиков софта заставить писать не в стиле «у меня всё нормально работает».

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

Он справляется, а ты нет. Он управляет Linux Kernel (крупнейшим опенсурсным проектом на планете), а ты в офисе пердолишься. При этом ему за 50. Так что сорян, skill issue. Git gut.

Кто-то штангу 200 кг жмёт, а ты и я нет. И что с того? Я не управляю Linux Kernel и мне вся эта возня с Арчем не нужна. Мне свою работу делать надо - сейчас на Go, раньше на Java.

Зачем пользоваться Fedora?

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

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

Да я бы был рад, если бы она была не нужна. Ещё бы разработчиков софта заставить писать не в стиле «у меня всё нормально работает».

Вот и для последнего нужна стандартизация. А иначе как их заставить?

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