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

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

Давай ты перестанешь совсем уж откровенный тупняк постить:

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

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

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

Не понимаю. Если все равно на чем, то зачем ему более совершенный инструмент?

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

А обязательно нужно что-то сказать? Я вижу очень много фанатиков, которые завидуют успехам дедов 30-летней давности и хотят альтернативную историю развития программирования. На каждый трейдофф, предложенный миром отвечают, что есть только си как язык программирования, и Ритчи его пророк, и всё тут.

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

где сами и будут её мейнтейнить.

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

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

Сколько ещё он будет есть? Перл тоже был вездесущь, когда-то.

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

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

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

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

Ядро это на 90% драйверы. Железячники тупые и Rust не осилят. Они и С осиливают весьма условно. Поэтому такой план не сработает.

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

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

а концептов как в Расте нету.

В расте нет концептов. Есть трейты, aka интерфейсы. Комптайм Zig значительно мощнее возможностей Rust по метапрограммированию.

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

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

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

да-да, ты еще скажи как та истеричка Мартин, «не хотят учить новые технологии». Как будто раст это новая технология, и как будто там есть что учить, лол

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

Вообще его автолулзы требуют. Так что…

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

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

Там обычно мода то на одно, то на другое. И всё из-за отстутсвия адекватного тулинга в GNU.

Потому что 3.13 ещё не было практически нигде.

И что это меняет? Питон принципиально ненадёжен в плане совместимости вниз. Завтра в 3.XX Питоне опять что-то сломают и опять придётся доводить это до ума. А раньше было время, когда во многих питоновских проектах пытались поддерживать ещё и второй Питон вмести с третьим. Даже Java была бы лучше, я серьёзно!

Потому что работает. Туда могут новое принести. Старое обычно не уносят.

Ну так и CMake тоже работает и даже более стабильно. Почему же не CMake?

Пффффф. Давай не будем начинать про Make (какую, кстати, его вариацию и какую версию этой вариации?). У cmake тоже недавно был мажорный бамп, когда кучу новых функций принесли.

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

Это не значит, что он жив. Просто glibc выкинуть дорого.

Просто у glibc всё ещё нет адекватных альтернатив. Про binutils и gdb ты почему-то промолчал.

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

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

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

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

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

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

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

Аналогии обычно используют в качестве иллюстрации.

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

Текущие поколения ИИ ошибки ведь совершают. Вполне можно ожидать, что и следующие поколения не будут идеальны.

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

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

ладно бы цру всех агитировало бы за аду

Но это тоже вызвало бы отторжение, просто по другой причине. Были бы срачи в стиле «сами пишите трактаты на этом многословном угрёбище. И ради чего?! Даже нет никаких гарантий утечек памяти и защиты от выстрела себе в ногу сырым указателем».

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

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

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

Там обычно мода то на одно, то на другое. И всё из-за отстутсвия адекватного тулинга в GNU.

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

И что это меняет? Питон принципиально ненадёжен в плане совместимости вниз. Завтра в 3.XX Питоне опять что-то сломают и опять придётся доводить это до ума. А раньше было время, когда во многих перловых проектах пытались поддерживать ещё и второй Перл вмести с третьим. Даже Java была бы лучше, я серьёзно!

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

Ну так и CMake тоже работает и даже более стабильно. Почему же не CMake?

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

GNU Make вполне хорош и именно под него написана куча софта или генерируются мейк файлы в куче софта.

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

Ну а большой бамп фич в CMake, разве он что-то поломал?

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

Просто у glibc всё ещё нет адекватных альтернатив.

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

Про binutils и gdb ты почему-то промолчал.

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

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

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

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

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

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

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

Да, Раст отпугивает дополнительной сложностью из-за borrow checking и немного инопланетным синтаксисом

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

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

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

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

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

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

Т.е. си менее строгий язык чем Rust?

Пожалуйста напишите 2 куска кода (на Си и Rust) и укажите почему кусок на Rust считается более строгим?

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

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

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

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

Чего там уже разрабатывать осталось кроме очка создателя?

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

А этим хотят решить задачу массовой разработки драйверов для тысяч девайсов

Пардон, а разве ЯП был причиной непопулярности Линукса для разрабов железа и драйверописателей?

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

Я вот не пойму, чего ржавые с таким упорством лезут в ядро?

Потому что в этом вашем ядре из-за дырявой Сишки регулярно находят критические уязвимости, позволяющие получить root доступ или вывести систему из строя (DoS). Серьёзный бизнес эта ситуация не устраивает и по этому внедряют Rust, который позволяет избавиться от целых классов уязвимостей. Почему не делают своё ядро на Rust? Ответ простой: постепенное переписывание компонентов ялра на Rust сразу приведёт к положительным изменениям и это менее трудозатратно.

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

Здрасьте, приехали… А почему тогда для винды писали драйвера в первую очередь, а не для Линукса, ещё когда раста не было даже в проекте?

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

Ну т.е. создали проблему, испортили workflow и заблокировали на время разработку совершенно третьим лицам, и лишь спустя какое-то время снизошли до того, чтобы за собой прибрать (когда дошло до Торвальдса).

Ровно то, о чем я написал.

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

Без биндингов драйвер на Rust не напишешь.

И что же мешает растофилам написать себе эти биндинги в коде своих драйверов? Если компилятор/линкер раста настолько убог, что не может в C ABI, а растофилы настолько неосиляторы, что не могут допилить свой компилятор/линкер чтобы оно могло, то что мешает положить в сырцы своего драйвера сырец с этими биндингами написанными на сишечке? Есть же например https://crates.io/crates/cc для этого.

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

Так что же на самом деле мешает растофилам создавать свои прекрасные «безопасные» out-of-tree драйвера без всего этого цирка с пропихиванием раста в ядро?

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

Я могу писать на C …

Я знаю многих кто пишет на Go, Python и получает достаточно много от 300 и не понимаю к чем Вы это написали.

Примерно то же и на ИИ можно спроецировать

Понимаете в чем главная ошибка … если бы люди думали как Вы (Вы меня извините я не хочу вас обидеть) то мы бы ездили на автомобилях где в место колес ноги, а у самолетов были бы крылья. ЯП как раз сделали чтобы люди программировали … ИИ никакие ЯП по идее не нужны и если кто то идет по этому пути они просто еще не поняли в чем суть.

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

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

Звучит очень страшно! Если бы это не происходило каждый вторник, наверное, это была бы проблема. Но это происходит, поэтому нет, не проблема. Стив добавит тест в rust в kernel test bot и все будет хорошо.

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

Так что же на самом деле мешает растофилам создавать свои прекрасные «безопасные» out-of-tree драйвера без всего этого цирка с пропихиванием раста в ядро?

Потому что Линус решил, что надо в ядре.

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

А куда они уйдут?

Есть очень много трёхбуквенных вариантов!

1. В BSD
2. Ну ты понял…

То есть драма намечается нехилая и повторение истории OpenBSD вполне вероятно.

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

Т.е. си менее строгий язык чем Rust?

Безусловно.

Пожалуйста напишите 2 куска кода (на Си и Rust) и укажите почему кусок на Rust считается более строгим?

char *get_string(void) {
    char string[] = "hello";
    return string;
}

void main(void) {
    char *s = get_string();
    printf("%s\n", s);
}
fn get_string() -> &String {
    let s = String::from("hello");
    &s
}

fn main() {
    let s = get_string();
    println!("{}", s);
}

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

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

Здрасьте, приехали… А почему тогда для винды писали драйвера в первую очередь, а не для Линукса, ещё когда раста не было даже в проекте?

Кто писал, когда писал? Вот у тебя есть человек лет 20. Ты ему говоришь: вот тебе сишка, мил человек. А он говорит: да это же говно для дедов, вы чего? И уходит в другую компанию писать код на Go. Сперва все хихикают «ха-ха хипстеры», а потом выясняется, что сишников либо нет, либо там такие хлебушки приходят, что лучше бы не приходили.

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

И что же мешает растофилам написать себе эти биндинги в коде своих драйверов?

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

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

То есть драма намечается нехилая и повторение истории OpenBSD вполне вероятно.

Не. Ни у кого из уходящих не наблюдается организаторского таланта, какой был у Тео. В основном это какие-то аутисты, которым не нравится «сраковая впопухоль».

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

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

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

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

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

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

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

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

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

А что изменит полная цитата. У нас есть следствие «под Линукс не достаточно дров», и есть причина А «Линукс непопулярен у пользователей, угрёбищный ГУЙ, stable API nonsense». И вот, вместо того, чтобы эти фундаментальные причины рассматривать, мы выдумываем другую причину, Б «но ведь на сишке никто не умеет программировать, давайте будем учить макак расту». Но решение проблемы Б никак не повлияет на решение проблемы А.

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

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

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

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