Раст всё ещё не готов для десктоп^W ядра. 🤦🏻‍♂️

Вы чего, упоролись так новости оформлять?

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

А что, разве си не может кинуть сегфолт? Или это другое?

Почему это не Talks? Упоролись уже со своим Растом.

Конечно, другое. Си просто напишет «Segmentation fault» и всё, а Раст ещё бросится объяснять, что за ошибка, где ошибка, что с этим делать. Тот ещё душнила этот Раст.

Нет. Это стандартная обработка exception-ов в Rust - в любой непонятной ситуации роняем процесс. Анон-новостник, правда, забыл упомянуть, что автор патчей считает, что можно обойтись и без этого. А вот то, что rust-core монолитный - вот это надо уже rust-team что-то решать.

Ждём бабах рустофанбоев!

возможность panic()

И что? В ядре не бывает kernel panic?

опасные попытки использования 128 bit типов (в ядре запрещено)

Может лучше убрать странные запреты?

Это стандартная обработка exception-ов в Rust - в любой непонятной ситуации роняем процесс.

На Rust нельзя написать долгоживущий процесс с обработкой исключений? Это же вроде безопасный язык, исключения не должны ничего портить.

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

Анонимы! Ну имейте совесть! Зачем постить НОВОСТИ от анонимов? Кому адресовать вопросы в случае необходимости? Высрал и побежал, а вы разгребайте?

а Раст ещё бросится объяснять, что за ошибка, где ошибка, что с этим делать

Срочно запретить, а то драйвера под Линукс будет проще писать. Только serial debugging, только хардкор.

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

возможность panic(),

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

неделимость библиотеки

Интересно, что ту понимается? Нельзя взять из библиотеки только нужные функции? Нельзя использовать разные версии библиотеки в разных драйверах?

и соответственно опасные попытки использования 128 bit типов (в ядре запрещено)

Да, переполнения вполне возможны.

бесполезность предложенных примеров драйверов.

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

Торвальдсу же, ну.

Сегодня он поверил в Раст

А завтра родину продаст!

А почему нет, или хотел сам скора срубить?

Кому адресовать вопросы в случае необходимости?

Корректорам и модераторам

О, а я с кем-то поспорил тут на ЛОРе по этому поводу. Походу, я выиграл! Вспомнить бы еще, с кем спорил

Обычно автор новости больше знает об обсуждаемом предмете. И в последнее время много новостей от анонимов. Это плохо. Кто-то стесняется? Или брезгует? Зачем тогда на лор ходит?

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

опасные попытки использования 128 bit типов (в ядре запрещено)

Может лучше убрать странные запреты?

Это не странные запреты, это кривой пересказ опеннета.

Может кого-то слишком часто банят и задолбало регать новые аккаунты?

Кому адресовать вопросы в случае необходимости?

Линусу Бенедикту Торвальдсу, очевидно же.

Подобные новости способствуют глобальному потеплению климата - у фанатов раста полыхнёт от всей души :-P

А Роботы-Гедонисты, они обрящут? Их же переплавить можно.

На Rust нельзя написать долгоживущий процесс с обработкой исключений?

В rust нет исключений. Есть Result<T, E> для исправимых ошибок и panic! для неустранимых (например ошибки malloc - это тоже исключения, конечно но смысл процессу жить тогда).

Собственно, всё в книге есть

Linux News Cycle http://phdcomics.com/comics/archive/phd051809s.gif

Теги расставлял выпускник МГИМО.

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

В Обероне все ошибки устранимые, включая переполнение стека, SIGSEGV, NULL dereference и прочие. Процесс неубиваем если его специально не сломать небезопасным кодом.

Нельзя взять из библиотеки только нужные функции?

Именно это

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

Ну так он и говорит: покажите хотябы что мы в результате этих телодвижений можем получить-то. Возможность - это круто, конечно, а профит-то в чём. Вот там Гугл, вроде как на opennet нам пишут, binder на rust дописывает, вот может его посмотрят.

У них нет Душы!!

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

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

Процесс неубиваем если его специально не сломать небезопасным кодом.

Даже SIGKILL не прокатит?

все ошибки устранимые

Да никто не спорит, что можно перехватить ошибку и продолжить процесс. Другое дело, что если такие исключения в принципе полезли, то значит твориться какой-то звиздец, что жить дальше в принципе уже бессмысленно и надо как-то корректно завершиться (это и есть макрос panic!). upd. Условно говоря, программист говорит: я ХЗ что тут дальше делать и как с этим жить, давайте уже всё шатдауним.

Удивительно

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

Просто эталон жёлтой новости.

опасные попытки использования 128 bit типов (в ядре запрещено)

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

браво, Маэстро!

Даже SIGKILL не прокатит?

Прокатит. Но SIGKILL по ходу выполнения процесса не возникает, он приходит только извне.

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

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

пока базовые структуры рантайма целы

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

возможность panic()

А возможность разыменования неправильного указателя (и ошибку сегментации) в C уже отменили что ли?

неделимость библиотеки

что-что?

соответственно опасные попытки использования 128 bit типов

ну можно сделать какой-нибудь дополнительный анализатор кода на использование «небезопасных типов» и panic, проверку на стиль, так сказать. решает проблему? К сожалению, style checker не сможет также легко обнаружить ошибки работы с памятью.

бесполезность предложенных примеров драйверов.

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

В общем, не критика, а какая-то истерика.

В nightly есть Box::try_new, ради Линуса стабилизировали бы

Возможность на встроенном ассемблере вызвать halt, как такое им?

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

Линус об этом же и пишет: для драйвера недопустимо помереть из-за невозможности выделить память.
В юзерспейсе скончаться на вызове std::alloc ок, а в ядре — не очень.

это означает или куска памяти нет

Для Оберона это штатная ситуация, возвращается NULL.

или куче трындец

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

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

Я думаю он все правильно сказал. Возможно ради ядра будет написан специализированый panic free std. Может быть ещё несколько применений

Я думаю он все правильно сказал. Возможно ради ядра будет написан специализированый panic free std. Может быть ещё несколько применений

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

Возможно ради ядра будет написан специализированый panic free std.

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

И что? В ядре не бывает kernel panic?

I may not understand the ramifications of when it can happen, so maybe it’s less of an issue than I think it is, but very fundamentally I think that if some Rust allocation can cause a panic, this is simply fundamentally not acceptable.

Allocation failures in a driver or non-core code - and that is by definition all of any new Rust code - can never EVER validly cause panics. Same goes for «oh, some case I didn’t test used 128-bit integers or floating point».

So if the Rust compiler causes hidden allocations that cannot be caught and returned as errors, then I seriously think that this whole approach needs to be entirely NAK’ed, and the Rust infrastructure - whether at the compiler level or in the kernel wrappers - needs more work.

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

Ограничение на отправку комментариев: только для зарегистрированных пользователей

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