Линус Торвальдс раскритиковал Rust в ядре

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

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

Си просто напишет «Segmentation fault» и всё, а Раст ещё бросится объяснять

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

Exactly my point. Вот получается раздизайнили API так что нельзя. И потому это попахивает гнильцой (С++). Типо «ну че ты такой дерзкий, пиши код хорошо, багов не делай, если че сам виноват»

try_push и подобные - самый простой выход. Их нет, я ною по поводу почему try_reserve добавили, а остальные try_ одновременно с ним - нет, в чем логика?

Так это, в ядро вроде не тащат Box, не тащат ни alloc, ни std. В ядре по идее должен быть какой-то свой KBox<T, Allocator> c fn new() -> Result<KBox<T, Allocator>, AllocationError>. Особенно учитывая, что в ядре больше одного способа выделить память.

ядре по идее должен быть какой-то свой KBox<T, Allocator>

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

Язык - тот же. Не все библиотеки Rust требуют alloc или std. И std ты туда в любом случае не впихнёшь.

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

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

Да даже на си когда пишешь там всё сильно специфичнее чем в юзерспейсе.

Зачем этот раст нужен? Давно уже надо ноду в ядро включить по просьбам трудящихся.

Этого они скорее всего никак не избегут. Вот сделать alloc совместимым - это да, это ещё возможно.

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

Думаю нет. Линус просто выдаст живительных люлей растаманам. Это им пойдет на пользу, они пофиксят свой язык. И после нескольких таких заходов Раст станет пригоден для написания модулей ядра. Ну это мое ИМХО.

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

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

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

Линус сказал: «давайте поглядим на этот ваш Rust»

Истерички заполонили интернеты криками «Линус сказал что любит Rust!!!»

Потом Линус сказал «Я поглядел на ваш Rust, ему не хватает того-то и того-то, и вот тут вот ещё судя по всему проблема»

Истеричек мотнуло в другую сторону «Линус сказал что не любит Rust!!!»

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

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

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

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

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

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

Это всё осложняет идиотский дизайн линукса, в котором malloc может вернуть указатель даже когда памяти не хватает и реально процесс сдохнет при попытке обращения к какой-нибудь (не обязательно этой) памяти. Поэтому в конфигурации по умолчанию malloc возвращает ошибки только когда задан ulimit у процесса, насколько я знаю. Но всё же C это не только про Linux, ну и ulimit тоже таки можно задавать и это не какая-то совсем уж экзотика.

Зачем ты пытаешься испортить адекватом традиционный новостной растосрач?

Оно и не для ядра было бы не плохо. Внезапно падающие программы — это зло.

Это первое, с чем столкнулся разработчик curl, когда решил воспользоваться библиотекой hyperium на «системном» языке Rust. Выходит, что Rust - такой «системный» язык, что при попытках использования его действительно в системном контексте обнаруживаются фундаментальные проблемы.

For example it immediately became obvious that Rust in general encourages to abort on out-of-memory issues, while this is a big nono when the code is used in a system library (such as curl).

https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/

Ну, если бы Rust был где-то там между прочим а также «системным», то можно было бы понять, что

The Rust standard library team is doing work on allocators, fallible allocations, etc., but that is very much a WIP. We hope that our usage and needs inform them in their design.

https://lkml.org/lkml/2021/4/14/1140

всё ещё находится в состоянии WIP. Но он же, якобы, в первую очередь «системный».

это как? или там унылый виртуальный стек вместо настоящего системного?

а как там переполнение стека отлавливается?

это как?

Защитная страница в конце стека и sigaltstack для обработчика сигнала. Обработчик сигнала переходит на точку восстановления.

а этот panic! можно проигнорировать из вызывающего кода?

целая страница? так у них тогда доступный размер стека уменьшается, для прикладного кода нормальное решение, но для ядра - так себе

целая страница?

Её любая ОС для каждого потока создаёт по умолчанию, в том числе и в ядре. 4096/8192 байт на поток в 64-битном адресном пространстве — это мелочи (защитная страница память не потребляет). Без защитной страницы переполнение стека не будет зарегистрировано и программа продолжит исполнение, портя память перед стеком незаметно для разработчика и пользователя.

но тут выходит, что дополнительная страница создаётся, кроме той, что создаёт ОС, если я правильно понял

что дополнительная страница создаётся, кроме той, что создаёт ОС

Нет, той, что создала ОС, достаточно.

ок тогда вопрос - почему тогда в С/С++ отловить переполнение стека нельзя? кроме как в отладке

ок тогда вопрос - почему тогда в С/С++ отловить переполнение стека нельзя?

Можно тем же способом, но это надо делать руками. В Windows доступно из коробки через SEH.

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

Ну, в общем-то, согласен. Я как понял, они и хотят делать кастомный аллокатор, который не panic!-ует при невыделении блока.

Это не функция, это макрос.

Аргументы весьма спорные.

Просто Линус думал скорее соскочит на Раст, и хотел почерпнуть примеров идеального кода. Не знает видно, что первый блин комом.

Наличие Box::try_new например подразумевает что должен быть Vec::try_push и так далее

https://github.com/rust-lang/rust/issues/48043

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

Есть Vec::try_reserve после успешного завершения которого можно будет просто сделать push и не бояться, но это 1) не та эргономики 2) попахивает тем как вещи делаются в С++ «вот талмуд документации, вы должны вызвать вот эти 7 функций в вот таком порядке иначе 2+2 не будет работать"

Но даже если написать 100500 X::try_Y, то будет не достаточно. По ходу нужны флаги для стандартной библиотеки вида no_panic, отрубающих весь непотреб. Т.е. все функции вызывающие panic, alloc_error_handler и т.п. из стандартной библиотеки (или liballoc), должны быть убраны этим флагом. Тогда компиляция с их неявным использованием не будет проходить, а обратная совместимость не пострадает (как минимум сильно не пострадает).

Не знаю какие планы были у разработчиков Раста, но по ходу теперь многое надо заново планировать на этот год. В том числе заводить у себя в трекере флаг linux_kernel. Иначе затягивание принятия Раста в ядро будет ударом ниже пояса.

А вот то, что было предложено патчем к ядру явно надо переписывать. А значит к ближайшему релизу ядра ничего не будет. Как минимум выкидывать https://github.com/Rust-for-Linux/linux/blob/f97160690a2164b6121650794e28b4a4dcf0c311/rust/kernel/allocator.rs и всё что на нём завязано.

А разве компилятор rust вместе со сборочной системой ядра не должен был использоваться без stdlib? Как собственно и компилятор C. А также без cargo. Пусть господин Торвальдс мигнёт, если это не так!

Без stdlib, да. И панику свою нужно писать. И аллокаторы там всякие, если нужны. А вот cargo сносить смысла нету.

Так это, в ядро вроде не тащат Box, не тащат ни alloc, ни std.

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

• https://github.com/Rust-for-Linux/linux/blob/f97160690a2164b6121650794e28b4a4dcf0c311/rust/kernel/allocator.rs
• https://lkml.org/lkml/2021/4/14/1089

В ядре по идее должен быть какой-то свой KBox<T, Allocator> c fn new() -> Result<KBox<T, Allocator>, AllocationError>. Особенно учитывая, что в ядре больше одного способа выделить память.

Почти тоже Торвальдс и сказал https://lkml.org/lkml/2021/4/14/1131

Вот сделать alloc совместимым - это да, это ещё возможно.

Вот тут и засада. Он тащит alloc_error_handler, которого не должно быть в ядре.

Ну и плюс ты сам говорил:

Особенно учитывая, что в ядре больше одного способа выделить память.

а SIGSEGV и NULL dereference в обероне по такому же принципу отлавливаются?

А вот cargo сносить смысла нету.

Это выкинут из дистрибутивов Linux. Точнее, вырежут всё растоговно, если оно будет требовать доступа в интернет для сборки.

а SIGSEGV и NULL dereference в обероне по такому же принципу отлавливаются?

Через обработчик сигнала, только нет необходимости в sigaltstack. В отличии от C/C++, в Обероне есть проверки диапазонов массивов и запрещена произвольная адресная арифметика так что SIGSEGV не приводит к фатальным последствиям и исполнение можно продолжить с точки восстановления (longjmp в обработчике сигнала).

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

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

В отличии от C/C++, в Обероне есть проверки диапазонов массивов и запрещена произвольная адресная арифметика

Такое есть в си и си++ на эльбрусе. Ну как есть, без маллоков реаллоков и прочего.

Такое есть в си и си++ на эльбрусе.

Как Эльбрус спасёт от dangling pointers/use after free, которые могут портить память?

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

Безотносительно того можно ли на практике отзеркалить crates.io или нет - это тонны гемора для административного стаффа и килотонны новых уязвимостей, связанных с подменой источников пакетов и самих пакетов на вредоносные. См. https://www.opennet.ru/opennews/art.shtml?num=54566 и еще 9000+ новостей про npm. Теперь и в ядре!

Оно и не для ядра было бы не плохо. Внезапно падающие программы — это зло.

Выкидывать панику в неожиданных для разработчика ситуациях дело обычное. Это упрощает разработку и отладку. Увлечение отловом всех ошибок в конечном итоге выходит за разумные рамки.

Хорошо. Ждем Царя, жарим попкорн.

Да он чёт с радаров пропал. Блог забросил. Канал в телегу удалил.

Это упрощает разработку и отладку.

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

Увлечение отловом всех ошибок в конечном итоге выходит за разумные рамки.

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

Там есть возможность только перехватить померший от паники дочерний процесс.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8cd1b7fa3af94c92d660ffb63619e6b9

Оказывается для Ядра нужна своя реализация стандартной библиотеки…

klibc - не, не слышали?

Вот это поворот!

klibc - не, не слышали?

Значительную часть кода можно повторно использовать (memcpy/*printf и т.д.). В Haiku так делается и заголовки те же самые. Но куча разумеется другая.

Оказывается для Ядра нужна своя реализация стандартной библиотеки…

Потом ещё окажется что ядра Windows нужно по другому допилить. И для XNU под родной айфон тоже по другому. А потом ребятки с разноцветными причёсками внезапно решат что системное программирование им больше неинтересно.

И для XNU под родной айфон тоже по другому.

Там разве разрешают делать сторонние драйверы?