LINUX.ORG.RU

Линус высказал своё мнение о Rust в ядре

 , ,


2

5

Поживем - увидим

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

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

Торвальдс полагает, что первоначальной областью применения Rust в ядре могут быть драйверы, поскольку их написание представляет собой множество небольших и независимых задач. «Может, это не самое интересное применение, но оно самое очевидное». Он добавил, что поскольку многие устройства предназначены не для всех процессорных архитектур, недостаток их поддержки в Rust – не такая большая проблема.

>>> Источник

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от DarkEld3r

<анекдот про суровых лесорубов и бензопилу>

как ты в компилетайм можешь что-то гарантировать в современных системах где кроме CPU десятки устройств с bus master dma и для тебя в общем случае они «чёрный ящик» ? Безопасный интреопт сегодня без аппаратной поддержки невозможен.

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

Я про errno. Тут гонки возникают. Исключения (правильно ли я понимаю?) в с++ обрабатываются в том же потоке, где и возникают. И мы точно знаем, что послужило причиной.

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

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

Не весь класс ошибок можно проверить этапе на компиляции.

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

Факторы 50 лет назад и сегодня разнятся. В С, например, пплохо поддержана многопоточность (возврат кода ошибок не рассчитан на многопоток).

Это утверждение очень спорное. Во-первых, здесь фигурирует скорее критика стандартной библиотеки, нежели языка. Сам по себе язык вполне самодостаточен, и на нём можно писать приложения любой сложности даже с отключённой стандартной библиотекой (libc). Да, придётся переизобрести отдельные вещи, но это возможно. Именно так и пишутся ядра операционных систем. То, что libc придумывалась, никаким образом не запрещает пересмотреть libc и сделать её более современной: задепрекейтить определённые подходы и внедрить новые. И тенденция в этом направлении проглядывается, но эволюция идёт медленно.

Например, на смену qsort приходит более адекватная qsort_r, позволяющая передавать указатель на произвольные данные, избавляя от необходимости использования глобальных переменных. Однако проблема этой функции в том, что на каждой платформе (Linux, BSD, Windows) qsort_r имеет свой отдельный прототип, что сводит все преимущества внедрения этой функции на нет. То есть, потребность в такой функции была, различные платформы её реализовали по-разному, но договориться (или стандартизировать) эту функцию так пока и не смогли.

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

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

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

Я про errno.

Вроде как во всех вменяемых libc errno давно лежит в thread local.

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

Я про errno.

Ну так это не совсем про возврат кодов. И errno ведь thread-local?.. То есть, если обрабатывать ошибку в том же потоке, то никаких проблем нет.

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

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

Это если ты их перехватываешь в том же потоке. Если нет - получай terminate.

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

как ты в компилетайм можешь что-то гарантировать в современных системах где кроме CPU десятки устройств с bus master dma и для тебя в общем случае они «чёрный ящик» ?

Вот именно, что что-то гарантировать можно, а что-то нельзя. Невозможность «гарантировать всё» не значит, что не надо и пытаться. Вопрос эргономики, конечно, тоже остаётся.

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

Идрис здесь был приведен как пример языка с зависимыми типами, который на практике позволяет проверять выход за границы динамически размерного вектора на этапе компиляции. Можете дальше пытаться мне доказать, что Идрис плохо, а Rust/C/etc – хорошо, но больше читать это сил моих нет.

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

Прочёл тему и комменты.

Похрен. Честно. Нормальному сишнику ни кто и ни что не помешает написать модуль ядра на нормальном языке программирования если этот язык – С. Остальным не поможет ни что. Даже rust не поможет. Так что, похрен.

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

а ты зачем дма приплел? - против лома нет приема

есть - IOMMU, или лучше TrustZone - с ним любой периферии SoC можно запретить доступ к любой области памяти включая MMIO

https://www.toppers.jp/en/safeg.html

тут тебе и твой чери не поможет

все ядра а не только CPU могут иметь CHERI - GPU, VPU, NPU и тд, у них только свой специфичный набор инструкций разный. Кроме непосредственных ошибок при работе с памятью есть еще и логические ошибки.

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

TrustZone ...

«На самом деле, технология TrustZone дает нам инструментарий, позволяющий предпринять ряд мер (разделить память доверенных и недоверенных программ, разделить доступ к периферии) для создания надежного барьера между Secure и Non-Secure. Но надежность этого барьера будет зависеть и от качества, и полноты реализации доверенного ПО.»

т.е. баги в доверенном ПО и вместо TrustZone будет Ass Hole.

все ядра а не только CPU могут иметь CHERI - GPU, VPU, NPU и тд, у них только свой специфичный набор инструкций разный. Кроме непосредственных ошибок при работе с памятью есть еще и логические ошибки.

логические ошибки? ты хочешь сказать что это CHERI будет отлавливать этот класс ошибок?!

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

баги в доверенном ПО и вместо TrustZone будет Ass Hole

типа любой твой говнокод на расте это доверенное ПО ? шёл бы в школу дурачек

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

Линус высказал своё мнение о Rust в ядре
Где ты увидел слово раст?

ты за С чтоли топишь ?

так что там с логическими ошибками? Их чери тоже отловит?

исключит развитие атак от ошибок которые не обнаружили в компилетайм. И да, для тупорылых - TrustZone защищает Trust от ошибок в Non-Trust а не наоборот.

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

я так думаю в раст тоже завезут зависимые типы =)

Их в хаскель-то завезти не могут. А в расте до сих пор ждём GAT, специализацию и прочее всякое.

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

ты за С чтоли топишь ?

у тебя выпал эксепшен, разматывай стек =)

так что там с логическими ошибками? Их чери тоже отловит?

исключит развитие атак от ошибок которые не обнаружили в компилетайм

логические как? там какой-то искусственный интеллект, понимающий что программист написал не то что имел ввиду?

да, для тупорылых - TrustZone защищает Trust от ошибок в Non-Trust а не наоборот.

хамло ты
а кто защитит Trust от ошибок в самом себе?

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

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

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

Тут главная разница в том, что в отличии от идриса (coq'а, agda'ы), где гарантии даёт компилятор, единственная гарантия которую может дать программист на «более обычном языке» звучит примерно так

Мамой клянусь! Не упадёт. Всё что надо делает!

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

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

единственная гарантия которую может дать программист на «более обычном языке» звучит примерно так

Мамой клянусь! Не упадёт. Всё что надо делает!

код на идрисе работает на железе, производители которого такую гарантию дают в лучшем случае, а чаще так

https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/pan...

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

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

Гм, спасибо за поясление.
Я попробую выразиться по-другому.

И с (условным) Идрисом/Коком/Агдой и без него у тебя есть проблема с отказом железа.

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

Но _подавляющее_ большинство ошибок в программе - это ошибки программиста написавшего эту программу.

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


А по поводу раста в ядре - я думаю надо пробовать, очень интересно поглядеть на результат. По-моему весьма стоит.

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

Идрис позволяет гарантировать что этих ошибок просто нет

если ничего не писать это тоже гарантия

А по поводу раста в ядре - я думаю надо пробовать

не могли бы вы пробовать там ?

https://github.com/flosse/rust-os-comparison

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

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

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

боишься без работы остаться?

на рынке ценится знание предметной области, на чём писать даже не второстепенно. Ты своими многопоточными «hello gpio» никого не заинтересуешь.

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

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

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

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

на рынке ценится знание предметной области

там ценится дешёвая раб.сила

Ты своими многопоточными «hello gpio» никого не заинтересуешь.

тебя заклинило на мультитреде? раст это «memory safe» & «thread safe» code.
и он успешно применяется в эмбеде.

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

для «hello gpio» один стек технологий был — Си и Ассемблер.
Нишу Си пришел потеснить Раст, вот у них и подгорает.

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

Для рантаймов существует набор формальных и неформальных стандартов и соглашений. Это, например позволяет свободно смешивать обьектный код полученный от различных трансляторов. Имбецилы создавшие Rust «пошли своим путем». В результате получился монстрик под который придется подганять почти все: подсистему памяти, драйвера, обрабочики прерываний, шедуллер, … Нужно быть дебилом что-бы ввязатся в этот ад.

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

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

А всё-таки можешь разжевать для тех, кто не в курсе «формальных и неформальных стандартов и соглашений»? Если что, мне правда интересно. Можно без особых подробностей.

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

пока кто-то думает, Гугл делает

увидел знакомое слово раст и возбудился ? если что этот BT стек работает в юзерспейс, в фуксии гугл так и вовсе явно запрещает использовать раст в ядре

https://fuchsia.dev/fuchsia-src/contribute/governance/policy/programming_lang...

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

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

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

В любой можно поставить. Не вижу смысла держать две разных версии gcc, если это не самая последняя и 2.95

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

А! Так оказывается, на расте пишут?

На расте пишут не потому что что-то мешает.

Ну ok, пусть пишут.

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