LINUX.ORG.RU

Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust

 ,


0

7

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

Линус раскритиковал действия Кристофа Хелвига, мэйнтейнера подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC. По мнению Линуса, Кристоф превысил свои полномочия и попытался повлиять на код, который не затрагивал код подсистемы DMA, был реализован в отдельном подкаталоге и не влиял на код, за который отвечает Кристоф. Кристоф попытался контролировать то, для чего используется подсистема DMA, и его действия можно сравнить с попыткой запрета использования DMA в каком-то драйвере, лишь потому, что ему не понравился этот драйвер. Итог: несмотря на то, что сопровождающие отвечают за свой код, они не отвечают за то, кто и как использует результат работы этого кода.

>>> Письмо Линуса

>>> Подробности (OpenNet)

★★★★★

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

Предыдущую новость на эту тему от @Alexandr_0503, мне, к сожалению, пришлось в форум перенести, поскольку там источник был на уровне «Линус с кем-то поговорил». Вот сейчас появилось письмо самого Линуса.

hobbit ★★★★★
() автор топика

Что есть файл: rust/kernel/dma.rs ?

mx__ ★★★★★
()

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

borisych ★★★★★
()

Такая новость просто лучшее что могло случиться в пятницу. Спасибки :3

perl5_guy ★★★★★
()

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

Честно говоря, Торвальдс не прав. Допустим в C коде изменения, которые ломают обвязки Rust. Что делать?

  1. Выпускать ядро со сломанным Rust.
  2. Блокировать выпуск ядра, пока не починят обвязки Rust.
atrus ★★★★★
()
Ответ на: комментарий от atrus

И если вдруг недостаточно понятно, то: Обвязки на Rust использует модуль на Rust, которые может требоваться конкретному мейнтейнеру для сборки и тестирования (например, модуль ssd переписали). Мейнтейнер работает с C кодом. Сломанные обвязки не дают ему возможность выполнить тестирование.

atrus ★★★★★
()

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

Осуждаю. Теперь после внесения любых изменений в си-коде подсистемы DMA, придётся проверять собираемость раст-компонентов, которые от неё зависят. И если эта собираемость нарушится, то что делать си-разработчику? Кидаться какашками через эту «защитную стену» в раст-разработчиков?

Beewek ★★★
()
Ответ на: комментарий от atrus
  1. Что есть такое обвязки Rust если в Rust есть тот же FFI к примеру?

  2. Ну допустим не хотя они напрямую дергать Си, почему их биндинг имеет название dma а не dma-api?

Иными словами это выглядит как начало переписывание dma на rust …

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

1. Чем вам поможет FFI, если изменились сишные функции из-за stable api nonsense?

2. Самая странная претензия. Какая разница как называется обвязка, если ей пользуется только rust-код?

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

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

Не очень понял.

  1. Чем вам поможет FFI, если изменились сишные функции из-за stable api nonsense?

А что делает разраб драйвера на Си использующим это?

Я думаю нужно определиться должны ли разрабы драйвера на rust следить за изменениями в си кода. В любом случае автор этой dma.rs должен будет следить за изменениями си кода. Ну или плюнуть на основную dma и переписать ЭТО на rust, но это уже по сути другая история.

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

на деле означает сломать «то, что было» и завалить работу?

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

Если Rust реально сможет сократить количество багов и уязвимостей, то он стоит того...

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

Нет, они собираются пихать свой (второй dma) интересно что там этот dma из других мест дергает, не собираются они это тоже на rust переписать …

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

Если Rust реально сможет сократить количество багов и уязвимостей, то он стоит того…

Ну так спорить с этим это другое. Могли бы просто заявить о переписывание всего ядра на rust (постепенно) и все, в чем проблема то?

Я читал что Торвальдс сказал что речи он переписывание уже рабочих компонентов нет …

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

Ждать, пока починят? Вообще за этим должен следить некто главный, который в курсе ситуации и кто на ком стоит. И если одно изменение ломает логику другого, то либо пинать второго, чтобы он чинил, либо как-то ещё разруливать.

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

Так именно так щас и модно же: переписать всё на новом чем-то просто ради переписать.

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

Если Rust реально сможет сократить количество багов и уязвимостей, то он стоит того…

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

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

А что делает разраб драйвера на Си использующим это?

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

Я думаю нужно определиться

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

В любом случае автор этой dma.rs должен будет следить за изменениями си кода.

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

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

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

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

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

Могли бы просто заявить о переписывание всего ядра на rust (постепенно) и все, в чем проблема то?

В том, что для этого всё равно нужен план. Желательно понятный всем участникам.

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

Нет я так не думаю, я раньше спрашивал - а что особенно им мешает написать ЭТО и на си.

Но затаскиваемый RUST в ядро выглядит именно как понижение квалификации писателей, иначе зачем им это …

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

Сам по себе язык ничего не может, что бы ни говорили его фанбои.

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

Создатели Rust всего лишь придумали способ заставить компилятор проверять и ругаться на распространённые ошибки работы с памятью. И? (При условии, что при разработке любого проекта, сложнее hello world, люди и так обмазываются valgrind"ами, статическими анализаторами)?

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

Ну.. Бытует мнение, что писать на этом сложнее, чем на си. Разве что если обмазать его ансейфами (или как их там), что нивелирует всю его «прелесть», но зато остаётся растом.

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

Честно говоря, Торвальдс не прав. Допустим в C коде изменения, которые ломают обвязки Rust. Что делать?

Мейнтейнеры Rust их чинят.

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

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

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

Создатели Rust всего лишь придумали способ заставить компилятор проверять и ругаться на распространённые ошибки работы с памятью. И? (При условии, что при разработке любого проекта, сложнее hello world, люди и так обмазываются valgrind"ами, статическими анализаторами)?

Всего лишь, лол.

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

Честно говоря, Торвальдс не прав. Допустим в C коде изменения, которые ломают обвязки Rust. Что делать?

Мейнтейнеры Rust их чинят.

Хрустальный шар подсказывает?

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

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

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

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

Я хз зачем юзать генератор который в любой момент может тебе дать ложную информацию. (мы от темы уходим)

mx__ ★★★★★
()

Надо ввести такой вид наказания за преступления: починка не собирающегося из-за раста ядра. Есть же там всякие общественные работы, и в США аналогичное должно быть. И назначать на такие работы айтишников-преступников. Вместо того, чтобы хакерить и бабло вымогать, пусть лучше общественно+полезную работу делают.

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

Или пусть те корпы, что на Линукс бабло пилят, скидываются в специальный фонд, из которого будут наниматься rust-ассенизаторы, которые при мейнтейнерах будут всё фиксить. А что? Ведь безопаснее означает дороже, вот пусть и будет всем видно, на сколько дороже, и почему. А то вскукарекнут всякие оналитеги «все на Раст!», а указать, что стоимость кода возрастёт, забывают, инфо-цыгане.

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

Ну.. Бытует мнение, что писать на этом сложнее, чем на си.

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

Второе выглядит проще. Но только выглядит. Я приведу пример. Вот был (и есть) ассемблер. Полная свобода. Загрузили значение в регистр - хотите используйте его как знаковое. И тут же как бесзнаковое. И тут же как адрес. Но почему-то в языках более высокого уровня победила система типизации, где компилятор бьёт вас по рукам, говоря, не важно, что размер объектов совпадает, вы не можете использовать этот объект здесь, потому что не совпадает такая эфемерная вещь, как тип. И да, у вас всё ещё остаётся возможность сказать в нужных местах «заткнись, я знаю, что я делаю» и применить unsafe прямое приведение типов.

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

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

Да, точно, вот примерно поэтому я перехотел щупать раст. Видимо, го с его нормальный GC меня приучил к хорошему (или плохому, как посмотреть).

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

Печалит, что в Rust полноценного наследования не сделали.

Он ведь рассматривается как заменитель не только C, но кое-где и C++…

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

И да, у вас всё ещё остаётся возможность сказать в нужных местах «заткнись, я знаю, что я делаю» и применить unsafe прямое приведение типов.

Воооот. А если так будет во всех местах, то нужен ли раст? Помню, тут был где-то тред, где рассмотрели код какого-то чего-то модномолодежного на расте, так там всё было в ансейфах.

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

поскольку там источник был на уровне «Линус с кем-то поговорил».

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

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

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

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

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

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

Воооот. А если так будет во всех местах, то нужен ли раст? Помню, тут был где-то тред, где рассмотрели код какого-то чего-то модномолодежного на расте, так там всё было в ансейфах.

Все это сколько? А то сейчас дойдем до того что куча примитивов в ядре на самом деле разворачиваются в asm() и будет неловко.

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

так там всё было в ансейфах.

Везде где дергаются сишные функции все будет unsafe.

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

Так это про си или зиг, а не про раст. Раст наоборот, помогает автоматизированно строить контракты.

neumond
()

Линус раскритиковал действия Кристофа Хелвига, мэйнтейнера подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC. По мнению Линуса, Кристоф превысил свои полномочия

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

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

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

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

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

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

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

И тебе говорили, что Линус вмешивается, когда проблема не решается сама:

I was hopeful, and I’ve tried to just see if this long thread results in anything constructive, but this seems to be going backwards (or at least not forwards).

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

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

zurg
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)