LINUX.ORG.RU

Линус Торвальдс запланировал внедрение Rust в Linux 6.1

 , , ,


4

6

Создатель ядра Linux и координатор его разработки Линус Торвальдс объявил на Kernel Maintainers Summit, что в Linux 6.1 будет доступно программирование модулей на Rust — «если не произойдёт ничего незапланированного».

Причиной включения Rust в ядро Торвальдс назвал более высокую безопасность языка (за счёт снижения числа ошибок работы с памятью) и его привлекательность для молодых разработчиков:

Rust - это одна из тех вещей, которые, как я думаю, привлекут новые лица… мы стареем и седеем…

Также опубликована начальная реализация драйвера rust-e1000 для Ethernet-адаптеров Intel. А компания Western Digital разрабатывает на Rust драйвер для NVMe-накопителей. Хотя драйвер ещё не оптимизирован, он не отстаёт в производительности от имеющегося ядерного драйвера на языке Си.

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



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

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

не про стиль а область применения

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от mx__

И кто тогда у Rust этот бакенд ?

LLVM.

LLVM много у кого бекенд: у D, C, C++, Swift, Rust, C#(один из возможных бекендов), Haskell, Zig и т.д.

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

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

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

А в чем реальный профит на пальцах? Что значит «бОльшая безопасность памяти»? Нельзя просто соорудить пару надстроек над С чтоб к массиву прибивался его размер (и указатель не мог выйти за его пределы) и указатель «выгрузить» чтоб компилятор проверял переменную на наличие освобождения динамической памяти в коде?

В Си тоже есть unsafe. Это дело программера юзать ЭТО или нет.

mx__ ★★★★★ ()

А вот интересно, сколько человек, из отметившихся здесь, что-то на Расте компилировали? Пять-шесть?

Вот сейчас собрал свеженький gitui. Да, хорошая утилита, удобная. Но 500K исходников за 5m 06s и 666Mb (смешно получилось)?! И это только в директории исходников.

Зато безопасно, да.

dataman ()

Два стакана смузи всем разработчикам.
Почитать, что ли, доков по расту...

thesis ★★★★★ ()
Ответ на: комментарий от no-such-file

Профит в том, что всё это чекается во время компиляции, а не динамически.

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

Собсно по аналогии с гет/сет бинов - задекларировал массив myArray, если так-же задекларирована переменная с заведомо определенным форматом имени, например myArrayCheckSize=10 то компилятору нет проблемы убедится что все указатели будут внутри массива.
Не хотца типовых имён? Ввести указатель на функциональные переменные - например @myArraySize=10 - тогда вообще ноль проблем со старыми прожектами и ляпота в новых

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

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

что такое в твоём понимании «самостоятельный язык» и как «ллвм и прочих» этому противоречат?

в моем понимании самостоятельность языка определяется наличием своего компилятора-линковщика. я неверно определил этот термин для себя?

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

в мою молодость не было фронта и бека. были компиляторы и линковщики :). наверное, с появлением ллвм стали использовать новую терминологию ибо бек в новом смысле, как я понимаю, несколько шире.

ergo ★★ ()

Кто-нибудь может объяснить, в чём проблема Раста, что для модулей на нём нужна специальная поддержка? Они компилируются не в машинный код? Они тянут большой рантайм? Они требуют особых аппаратных привилегий?

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

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

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

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Какой-то может быть и написан.

Ничего, я просто хотел уточнить структуру компиляторов.

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

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

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

Вот сейчас собрал свеженький gitui

Три месяца назад поставил наиновейший Debian Linux 11.

Результат компиляции:

error: failed to parse manifest at `/home/xi/work/develop/rust/gitui/Cargo.toml`

Caused by:
  failed to parse the `edition` key

Caused by:
  this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.

Xintrea ★★★★★ ()

Максимально зажатый и зарегулированный язык, он противоестественен духу свободного программного обеспечения и философии Linux. Если он и привлечёт в ядро «новые лица», то совсем с другим мировоззрением. Боюсь, что это будет большая ошибка Линуса…

x-signal ()
Ответ на: комментарий от fsb4000

Сейчас примерно такое понимание как я написал

«Сейчас»?

Открываю «Построение компиляторов» Вирта, 1985, и вижу там эти понятия. Они уж сто лет не менялись.

unsigned ★★★ ()

Последний гроб в шляпку гвоздя C++

perl5_guy ★★★★★ ()
Ответ на: комментарий от x-signal

За «духом СПО» нужно идти в HURD (правда, он почему-то до сих пор не работает, но это просто случайность, главное что его хакеры пишут!), а философия Linux это чисто инженерный подход.

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

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

Тебе кто-то запрещает писать на Rust-е то что ты хочешь?

Главное достоинство Rust-а в том, что он не даст тебе возможности сделать ошибку при доступе к памяти переменной, потому что концепция владения вшита в сам язык. Но даже это не гарантирует отсутствие утечек памяти. Rust гарантирует что ты работаешь с реально существующим объектом, но не гарантирует, что пока ты добрался до данного объекта, память не засралась не удаленными артефактами работы программы. Какая тут нафиг зарегулированность.

Xintrea ★★★★★ ()

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

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

Но даже это не гарантирует отсутствие утечек памяти

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

x-signal ()
Ответ на: комментарий от x-signal

Чтобы не было ошибок доступа к памяти может нужно просто писать код внимательнее

А чтобы не было войн, надо просто не конфликтовать 🤗

alex1101 ()
Ответ на: комментарий от x-signal

Чтобы не было ошибок доступа к памяти может нужно просто писать код внимательнее

Вот так программирование и превращается в упражнение на внимательность.

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

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

Если без маркетинга (зачастую вредного) про безопасность, то поинт очень простой: контроль над алиасингом.

Вот пост Линуса про алиасинг: https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing/

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

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

quantum-troll ★★★★★ ()
Ответ на: комментарий от sparkie

Господа, я сплю? Ущипните меня.

Добро пожаловать в реальность

GREAT-DNG ()

коменнтарий про «всю суть линукса» уже был?

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

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

Байндинги чего к чему? Раста к API ядра? Или Си к чему-то на Расте? Если первое, почему этим занимаются в LKML а не на сайте Раста?

olegd ★★★ ()

ведро стало настолько большим что в него со свистом помещается Rust :-)

общая проблема не в «большей безопасности алисов над ссылками», а в том что ядро стало слишком велико и сложно управляемо. Ждём Minix-X :-) Или что-нить подобное

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

Отлично. Стоим на пороге нового шага к развитию Linux.

Согласен. Так-то Linux стоит на краю пропасти, а теперь сделает огромный шаг вперед.

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

Сам язык же при этом не меняется

Без специальной поддержки со стороны языка придётся городить статический анализатор. Такие инструменты есть, но они не дают 100% гарантии.

no-such-file ★★★★★ ()
Ответ на: комментарий от fsb4000

Это только фронтенд.

Вот внедрим в LLVM код на расте, будешь знать!

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

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Для gcc вернее сказать наоборот: C написан на C++.

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

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Так наоборот же. Это у C сегодня все актуальные компиляторы написаны на C++. Что GCC, что Clang/LLVM, что MSVC.

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

В данном случае актуальнее чтобы существовало больше одной реализации языка.

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

а есть планы довести раст до самостоятельного языка без всяких ллвм и прочих?

Эти планы точно там же, где планы по доведению vim/emacs/vscode до самостоятельных IDE без всяких language server’ов, плагинов и прочих

Nexmean ()

Кстати, напомните, ядро наконец-то начало собираться Clang’ом нормально по дефолту?

Или луддиты всё так же теребонькают несовместимые со стандартом GCC Extensions?

EXL ★★★★★ ()
Ответ на: комментарий от no-such-file

Часто проблемы бывают неочевидные

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

x-signal ()
Ответ на: комментарий от rukez

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

Прочитайте TAPL и перестаньте задавать глупые вопросы. Различные системы типов способны давать гарантии совершенно различного уровня.

Nexmean ()
Ответ на: комментарий от no-such-file

В этом смысле Раст тоже не преемник, т.к. он никогда не станет «народным» языком, каким стал Си.

А что такое «народный язык»?

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

Наверно, никакой, если придумать что в целом делать с interoperability. Кроме ввода/вывода, нужно ещё много всякого другого api ядра использовать.

fang ()
Последнее исправление: fang (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.