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

Тут проблема не в panic() как в таковом, а в том, что нельзя обработать нехватку памяти. В том же C++ есть std::bad_alloc.

Разрывы жоп прикладников, которые не видят разницы между userspace и kernelspace

А её по хорошему нет. Просто последствия от говнокода в ядре намного серьёзнее.

когда человек не сталкивается с трудностями, он деградирует

Оберон-то может и переживёт, но что станет с состоянием программы будет зависеть как обычно от программистов.

Проблема в том, что при обработке нехватки памяти вызывается пинк.

Исключения и их обработку в Rust не завезли? В Оберон и C++ давно завезли. Или им религия не позволяет кидать исключения нехватки памяти?

В том же C++ есть std::bad_alloc.

А в расте теперь есть try_new.

А в расте теперь есть try_new.

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

А её по хорошему нет.

Хорошо. Будем делать в kernelspace сисколы в ядро, которого нет.

Просто последствия от говнокода

Иди в рассылку им напиши, какой ты умный, а мы тут посмеемся.

Для ядра можно ограничить апи try_* вариантами. А в юзерспейсе OOM killer как решать будем?

В ядре не будет сегфолта, будет паника. Но здесь не совсем понятно, что имеет ввиду Линус.

Будем делать в kernelspace сисколы в ядро, которого нет.

В Windows и Haiku можно вызывать системные вызовы через библиотеку как из программ, так и из ядра. А по номерам вызывать — это bad practice везде.

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

Для ядра можно ограничить апи try_* вариантами.

…и поломать почти всю стандартную библиотеку. Не вариант.

А в юзерспейсе OOM killer как решать будем?

Одно другому не мешает.

Особый вариант stdlib для ядра - это как раз то, что будут делать.

Линус Торвальдс изнасиловал анонимуса-растохейтера

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

Сисколы из ядра вызывать - вообще говнокод какой-то.

Имеется в виду экспортированные функции для системных вызовов. Для ядра они экспортированы самим ядром, а в пространстве пользователя они под теми же именами экспортированы в libc, libroot.so (Haiku), ntdll.dll (Windows).

А в этом кто-то, кроме этого самого кого-то виноват?
(Да, были случаи, когда я считал чей-то бан несправедливым, но эти люди как раз новые аккаунты не регали и под анонимусом, имхо, не писали. Они просто ушли.)

Особый вариант stdlib для ядра - это как раз то, что будут делать.

Не жалко им времени и сил… Почему так сложно сразу сделать нормально и универсально?

Новости от анона - это что-то новое.

Новости от анона – редкость, но то и дело публикуются.

Почему так сложно сразу сделать нормально и универсально?

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

Раст - системный язык общего назначения с (сюрприз) ограниченным количеством разработчиков и доступного им времени. Обрабатывать OOM в юзерспейсе нужно раз в квартал. Поэтому сразу не стали делать.

Кидать std::bad_alloc — это так сложно? Оберон — это очень простая система, которая полностью компилируется за секунды, и там всё работает.

Раст - системный язык общего назначения с (сюрприз) ограниченным количеством разработчиков и доступного им времени.

Поэтому надо делать ещё одну stdlib для ядра, вместо того чтобы починить new(). Логика.

В NetBSD, кстати, поддержка Lua есть.

Почитал.

on the whole I don’t hate it

Но анон вбросил так, словно он его с говном сравнял и хрусту в ядро закрыта дорога.

Просто указал на явные проблемы, которые стоит решить перед тем, как пихать это в продакшен.

Кидать std::bad_alloc — это так сложно?

Исключения и stack unwinding в ядре - это то ещё приключение. И как-то нужно гарантировать отсутствие выделений памяти в cleanup коде.

Поэтому надо делать ещё одну stdlib для ядра.

И не ещё одну stdlib, а конфигурируемую stdlib с возможностью отключения фич не поддерживаемых в kernel space, но удобных в user space.

Пришел анон и швырнул огрызок с опеннета. ЛОР, куда ты скатился? :(

да, прям так и сказал:
кто пишет драйверы на Rust
тот настоящий...сжв

а разве panic() в сишных драйверах невозможен?

Если одна и та же хрень, то «зачем платить больше»?

Вроде и правильно, но вроде как это примеры, а не драйверы…

Это вроде как очень хреновые примеры если из них непонятно на кой чёрт этот раст в ядре сдался.

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

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

Что, блин, про это можно «больше знать» - там всего несколько абзацев элементарного английского, написанного финнским шведом. Потрать полторы минуты и будешь знать ровно столько же сколько и автор новости.

ЛОР, куда ты скатился? :(

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

Шапито. В core нет кода, который бы выделял память. Разве что кроме памяти, выделяемой на стеке при вызове функций. И панику можно спровоцировать разве что руками.

Сегодня пишет он на раст, а завтра Родину предаст!

а вот это вообще удар ниже пояса - https://lkml.org/lkml/2021/4/14/1091

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

Что не так, нормальная просьба. Только на ЛОРе когда Линус говорит «Вау, охрененно, я разрешил Раст в ядре, у меня много энтузиазма увидеть реальный драйвер на нем», то местные борцуны слышат «Хахаха, ваш Раст ничего не может дальше хелловорлда, ставлю 500 баксов что у вас ничего не выйдет»

просьба то нормальная, вот только у растеров, боюсь, осилить ее не получится

Тут проблема не в panic() как в таковом, а в том, что нельзя обработать нехватку памяти. В том же C++ есть std::bad_alloc.

Линус:

Because kernel code is different from random user-space system tools. Running out of memory simply MUST NOT cause an abort. It needs to just result in an error return.

просьба то нормальная, вот только у растеров, боюсь, осилить ее не получится

Почему?

Смотрите чё я нашел, ребзя. Ещё не читал сам :3

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

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

Ну там ребятки сами ССЗБ в какой-то степени.

1 - там no_std во все поля будет, ну или сабсет перепиленый.
2 - паника - там с одной стороны специфичный кейс, с другой - может таки пофиксят старую проблему, что ошибка выделения памяти - это паника. Так называемые failable allocations давно напрашиваются, но всем как обычно.

Короче Линус всё правильно им втыкает, может таки начнут шевелиться.

А можно настроить Rust, чтобы без try оно просто не работало? Типа если не вызвал Vec::try_reserve, то push не сработает.

Там нет исключений же. Суть претензий примерно такая: если какой-то чудила использовал panic!(), то ядро в неё и уйдёт. Вроде всё верно? А вот тут имеем кейс типа:

let a = Box::new::<Zalupa> ();

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

И таких нюансов закопано довольно много.

Running out of memory simply MUST NOT cause an abort. It needs to just result in an error return.

std::bad_alloc этому не противоречит. Главное обработать все исключения перед возвратом в код ядра.

Исключения и stack unwinding в ядре - это то ещё приключение.

В ядре Windows работает без проблем (SEH). Можно сделать обработку исключений через setjmp/longjmp и регистрацию cleanup-обработчиков примерно как в Обероне.

Там нет исключений же.

В Rust вообще нет никаких исключений? Тогда он ещё примитивнее чем Go.

Отсутствие исключений - архитектурное решение. Так что да, религия.

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

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

Насчёт примитивнее - не скажи, они местами друг-друга стоят(да, я сейчас пишу на обоих))

но восстановиться из него ты ЕМНИП не можешь.

Через longjmp можно, но не будут вызваны деструкторы стековых переменных.

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