LINUX.ORG.RU

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

 ,


3

9

Линус Торвальдс критикует использование Rust в ядре. Причины: возможность panic(), неделимость библиотеки и соответственно опасные попытки использования 128 bit типов (в ядре запрещено), бесполезность предложенных примеров драйверов.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: alpha (всего исправлений: 3)

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

beck ★★★★
()

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

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

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

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

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

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)

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

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

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

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

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

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

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

X512 ★★★★★
()

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

cocucka ★★★★☆
()

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

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

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

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

X512 ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

TheAnonymous ★★★★★
()

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

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

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

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

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

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

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

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

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

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

LamerOk ★★★★★
()

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

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

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

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

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

SkyMaverick ★★★★★
()

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

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

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

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

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

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

Именно это

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

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

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

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

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

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

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

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

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

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

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

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)

Удивительно

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

d_a ★★★★★
()

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

intelfx ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

SkyMaverick ★★★★★
()

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

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

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

что-что?

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

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

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

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

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

BattleCoder ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

SkyMaverick ★★★★★
()

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

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

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

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

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

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

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

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

И что? В ядре не бывает 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.

fernandos ★★★
()

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

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

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

crutch_master ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.