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 ()

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

Кстати, разве у gcc когда-то был публичный промежуточный IR? Именно оформленный в стабильный язык как у LLVM, а не какие-то внутренние структуры.

  • GENERIC - синтаксическое дерево
  • GIMPLE - собственно сам IR

Можно запустить gcc с ключом -fdump-tree-all-raw и смотреть.

Вот, например, под катом простая программа (ну, первая, которая у меня в екзамплах валяется) и её IR (просто компиляция, без опций)

Код:

#include <sys/socket.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <string.h>
#include <net/if.h>
#include <errno.h>
#include <stdio.h>

int
main()
{
    int sock;
    struct sockaddr_in *in_addr;
    struct ifreq ifdata;
    struct if_nameindex *ifNameIndex;

    sock = socket(AF_INET, SOCK_DGRAM, 0);

    if (sock < 0) {
        printf("Не удалось открыть сокет, ошибка: %s\n", strerror(errno));
        return 1;
    }

    ifNameIndex = if_nameindex();
    if (ifNameIndex) {
        while (ifNameIndex->if_index) {
            memset(&ifdata, 0, sizeof(ifdata));

            strncpy(ifdata.ifr_name, ifNameIndex->if_name,
                    IFNAMSIZ);

            if (ioctl(sock, SIOCGIFADDR, &ifdata) < 0) {
                printf("Не получить IP адрес для %s, ошибка: %s\n", ifdata.ifr_name,
                       strerror(errno));
                //close(sock);
                //return 1;
            }
sockaddr_in
            in_addr = (struct sockaddr_in *)&ifdata.ifr_addr;
            printf("Интерфейс %s индекс %i IP адрес: %s\n", ifdata.ifr_name, ifNameIndex->if_index,
                   inet_ntoa(in_addr->sin_addr));
            ++ifNameIndex;
        }
    }

    close(sock);
    return 0;
}

GIMPLE, который низкоуровневый, но так-то и высокоуровневый есть

int main ()
{
  struct if_nameindex * ifNameIndex;
  struct ifreq ifdata;
  struct sockaddr_in * in_addr;
  int sock;
  int D.3194;

  gimple_try <GIMPLE_TRY_FINALLY,
    EVAL <
      gimple_call <socket, sock, 2, 2, 0>
      gimple_cond <lt_expr, sock, 0, <D.3192>, <D.3193>>
      gimple_label <<D.3192>>
      gimple_call <__errno_location, _1>
      gimple_assign <mem_ref, _2, *_1, NULL, NULL>
      gimple_call <strerror, _3, _2>
      gimple_call <printf, NULL, "\xd0\x9d\xd0\xb5 \xd1\x83\xd0\xb4\xd0\xb0\xd0\xbb\xd0\xbe\xd1\x81\xd1\x8c \xd0\xbe\xd1\x82\xd0\xba\xd1\x80\xd1\x8b\xd1\x82\xd1\x8c \xd1\x81\xd0\xbe\xd0\xba\xd0\xb5\xd1\x82, \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd0\xb0: %s\n", _3>
      gimple_assign <integer_cst, D.3194, 1, NULL, NULL>
      // predicted unlikely by early return (on trees) predictor.
      gimple_goto <<D.3199>>
      gimple_label <<D.3193>>
      gimple_call <if_nameindex, ifNameIndex>
      gimple_cond <ne_expr, ifNameIndex, 0B, <D.3195>, <D.3196>>
      gimple_label <<D.3195>>
      gimple_goto <<D.3189>>
      gimple_label <<D.3190>>
      gimple_call <memset, NULL, &ifdata, 0, 40>
      gimple_assign <component_ref, _4, ifNameIndex->if_name, NULL, NULL>
      gimple_call <strncpy, NULL, &ifdata.ifr_ifrn.ifrn_name, _4, 16>
      gimple_call <ioctl, _5, sock, 35093, &ifdata>
      gimple_cond <lt_expr, _5, 0, <D.3197>, <D.3198>>
      gimple_label <<D.3197>>
      gimple_call <__errno_location, _6>
      gimple_assign <mem_ref, _7, *_6, NULL, NULL>
      gimple_call <strerror, _8, _7>
      gimple_call <printf, NULL, "\xd0\x9d\xd0\xb5 \xd0\xbf\xd0\xbe\xd0\xbb\xd1\x83\xd1\x87\xd0\xb8\xd1\x82\xd1\x8c IP \xd0\xb0\xd0\xb4\xd1\x80\xd0\xb5\xd1\x81 \xd0\xb4\xd0\xbb\xd1\x8f %s, \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd0\xb0: %s\n", &ifdata.ifr_ifrn.ifrn_name, _8>
      gimple_label <<D.3198>>
      gimple_assign <addr_expr, in_addr, &ifdata.ifr_ifru.ifru_addr, NULL, NULL>
      gimple_call <inet_ntoa, _9, in_addr->sin_addr>
      gimple_assign <component_ref, _10, ifNameIndex->if_index, NULL, NULL>
      gimple_call <printf, NULL, "\xd0\x98\xd0\xbd\xd1\x82\xd0\xb5\xd1\x80\xd1\x84\xd0\xb5\xd0\xb9\xd1\x81 %s \xd0\xb8\xd0\xbd\xd0\xb4\xd0\xb5\xd0\xba\xd0\xb5\xd1\x81 %i IP \xd0\xb0\xd0\xb4\xd1\x80\xd0\xb5\xd1\x81: %s\n", &ifdata.ifr_ifrn.ifrn_name, _10, _9>
      gimple_assign <pointer_plus_expr, ifNameIndex, ifNameIndex, 16, NULL>
      gimple_label <<D.3189>>
      gimple_assign <component_ref, _11, ifNameIndex->if_index, NULL, NULL>
      gimple_cond <ne_expr, _11, 0, <D.3190>, <D.3188>>
      gimple_label <<D.3188>>
      gimple_label <<D.3196>>
      gimple_call <close, NULL, sock>
      gimple_assign <integer_cst, D.3194, 0, NULL, NULL>
      gimple_goto <<D.3199>>
    >
    CLEANUP <
      gimple_assign <constructor, ifdata, {CLOBBER}, NULL, NULL>
    >
  >
  gimple_assign <integer_cst, D.3194, 0, NULL, NULL>
  gimple_goto <<D.3199>>
  gimple_label <<D.3199>>
  gimple_return <D.3194>
}

Там дальше и последующие шаги трансляции можно посмотреть в остальных сгенерированных файлах.

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

Так это фактически сишный AST с парой небольших изменений. Другие языки в это компилировать примерно так же «легко», как и в сам C.

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

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

Так это фактически сишный AST

GENERIC - да, заточен под Си, но можно использовать свой. Как в доке пишут, тотже Fortran-фронт использует не gcc-шный GENERIC/AST, а транслирует уже в GIMPLE. И никого не обламывает.

GIMPLE - как раз IR. Собственно, линеаризованное дерево.

Другие языки в это компилировать примерно так же «легко», как и в сам C

LLVM IR, можно подумать, сильно принципиально другой. Разве что конструкции короче, а так +- логика та же.

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

Если тебе меньше 50 лет, то были.

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

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

Нет. LLVM IR — это именно ассемблер регистровой виртуальной машины. Здесь же гораздо более высокоуровневый практически сишный код с сишной семантикой, судя по всему.

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

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

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

Принципиально никакой разницы. Тотже линеаризованый граф, описавающий поток и управление линейными блоками.

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

Ну и да, GCC под GPL, что корпам оптимизма не добавляет.

Вообще, вот на SO дали хороший, развернутый коммент по поводу отличий GIMPLE и LLVM IR, с которым, в принципе, можно согласиться.

SkyMaverick ★★★★★
()

Такими темпами скоро на typescript модули ядра можно будет писать

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

GIMPLE (GCC’s IR) was never considered to be more than an implementation detail, in particular it doesn’t provide a full description of compiled program (e.g. it lacks program’s call graph, type definitions, stack offsets and alias information).

Да, я примерно это и имел ввиду.

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

Разделение на фронт и бэк в компиляторах было где-то с 80х, если не раньше. Это разве что первые версии си компилировались построчно в машинный код для pdp-11 (отсюда заточенность под однопроходный компилятор, которая даже из C++ до сих пор никуда не делась). Просто программистам это редко нужно и в IR компилятора они не смотрят.

К слову, этих самых IR в одном компиляторе может быть много. В GHC их например три, и все разные: Core -> STG -> C––.

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

Раст претендует на звание языка, который заменит все системные языки. Так чего бы не запилить свой компилятор? Драйверы в Linux взялись писать с целью «обучения и выявления подводных камней», так чего бы не написать полноценный компилятор с той же целью? Или написание компиляторов - задача для растаманов слишком сложная?

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

Раст претендует на звание языка, который заменит все системные языки. Так чего бы не запилить свой компилятор?

Какая логическая связь между одним и другим?

alex1101
() автор топика

Кстати, я что-то пропустил или rust уже умеет использовать бекенд gcc? Или теперь llvm официальная зависимость?

atrus ★★★★★
()

теперь собрать ведро можно будет только на суперкомпьютере ?

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

Ну, есть cranelift, если хочется прям бекенд компилятора на расте.

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

конец эпохи …

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

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

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

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

А как вы из любого языка будет использовать макросы Си? Хотя бы уровня:

#define __pfn_to_page(pfn)      (mem_map + ((pfn) - ARCH_PFN_OFFSET))
ИМХО, проблема не написать модуль, а написать его так, чтобы его не требовалось переписывать, когда в ядре какой-нибудь define поменяют.

Интерестно, добавляемые Rust-абстракции, не будут ли содержать код, дублирующий сишный...

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

А как вы из любого языка будет использовать макросы Си? Хотя бы уровня:

Придется какую-то обвязку иметь для вызова подобных как бы фукнций по семантике.

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

Кстати, разве у gcc когда-то был публичный промежуточный IR? Именно оформленный в стабильный язык как у LLVM, а не какие-то внутренние структуры.

Похоже был, т.к. они его закрывали и запрещали использовать фронтенд без стандартного бэка. Я, к сожалению, не помню версию на которой это всё произошло, но дело давнее.

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

они его закрывали и запрещали использовать фронтенд без стандартного бэка.

Свободное ПО лол. GPL во все поля!

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

Свободное ПО лол. GPL во все поля!

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

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

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

Ичо? Они это в нарушение GPL делали? Нет. На этом и всё. На любую хитрую жопу (GPL) всегда найдётся болт с левой резьбой.

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

На любую хитрую жопу (GPL) всегда найдётся болт с левой резьбой.

(аплодисменты переходящие в овацию) какие молодцы «этиваши» корпорации! ;)

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

Они это в нарушение GPL делали? Нет.

«ага, игнорирование лицензию не нарушает» - думает пользователь и начинает пиратить пользоваться продуктами корпораций игнорируя лицензии корпораций. Аплодисменты в его адрес будут? (ответ я знаю)

У меня такая картинка сложилась.

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

«ага, игнорирование лицензию не нарушает» - думает пользователь и начинает пиратить пользоваться продуктами корпораций игнорируя лицензии корпораций. Аплодисменты в его адрес будут? (ответ я знаю)

В каком месте игнорирование? Они не выкладывали исходники gcc и всего что с ним слинковано? Наверняка же выкладывали. То, что высер части gcc используется в другом коде, так это вообще повсеместная практика. Это компилятор, как никак!

Я помню другой срач: Штальман очень негодовал, что фронты gcc могут использовать для создания проприетарных IDE, и поэтому внутренности gcc онально огородили. А жаль. Мы могли иметь аналог lsp/clangd на 10 лет раньше.

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

Твой оппонент утверждал, что игнорировали (нарушали) GPL. Ты утверждал, что нет. Я описал своё восприятие

У меня такая картинка сложилась

не примыкая к какой-либо точке зрения.

Что касается, гипотетического пользователя-игнорирователя лицензий – я подчеркнул разницу между «корпорациями» («Зевсом») и хомячком («быком»).

Да меня «взрывает» от двойных стандартов, но других на этой планете и нет. (

Штальман очень негодовал, что фронты gcc могут использовать для создания проприетарных IDE, и поэтому внутренности gcc онально огородили.

Это… Это просто эпикфейл в кубе. Теперь твоя фраза про болт с левой резьбой заиграла новыми красками. )

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

Твой оппонент утверждал, что игнорировали (нарушали) GPL. Ты утверждал, что нет. Я описал своё восприятие

Погоди.. я думал, вы оба один и тот же чувак. У обоих master в нике.

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

Вообще, я по аватаркам различаю людей. И у них обоих её нет.

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

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

Dark_SavanT ★★★★★
()

Руст и задумывался как замена си и с++. Как только он будет готов - сразу его начнут внедрять в ядро. Как только в ядре появится и оттестируют - сразу всё ядро планомерно перепишут на руст. Как только ядро перепишут - большинство софта переедет с си на руст. Это может кому-то нравится или не нравится, но это произойдет

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

Так с точки зрения пользователя rustc ллвм это тупо библиотека, деталь реализации тулчейна.

Ну то есть вот яббл сделал свой Swift. Под капотом — LLVM. Тоже, получается, несамостоятельный язык?

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

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

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

Да, но во-первых например Go в каком-то смысле managed язык (хоть и компилируемый). Плюс, его делают гуглы, чей подход к решению любой задачи это «форкнуть и/или закидать людьми». Плюс, из Go торчат уши Plan 9 — то есть они тоже начинали не с нуля, они форкнули тулчейн Plan 9, что и задало вектор его развития.

Короче, го — это во многом уникальный случай.

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

С точки зрения безопасности на данный момент полностью «суверенный» код имеют только китайцы: gcc->kernel->native_cpu. То есть они уверены что ни одного бэкдора в их цепочке не будет. В нашем случае( Россия ) такого полностью «суверенного» кода нет. gcc->kernel->elbrus: gcc - вроде суверенно, ядро - с помощью этого gcc вроде суверенно, elbrus - не сувереннен( изготавливается не у нас ). В случае раста - опять нарушается принцип «суверенизации». Именно с этой точки зрения и китайцам и нам этот рас нах… не нужен. Сейчас. Чтобудет после окончания войны - Бог знает. Скорее всего запада не будет.

mke61
()

Вставлю свои 5 копеек.

Решил поинтересоваться, что же представляет собою Rust? Начал читать книгу «The Rust Programming Language» (в русском переводе).

Пока прочёл первые 5 глав. И надо сказать, что не зря Линус Торвальдс за Rust. Я теперь понимаю почему скажем, не D. D как системный язык без сборщика мусора, а значит и стандартной библиотеки представляет собой довольно грустное действо.

Rust же обладает весьма интересными концепциями обеспечивающими безопасность памяти и без GC. А какой вывод ошибок у компилятора? Это просто шедевр, подробнейший! Я такого подробного ещё нигде не видел.

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

Как только в ядре появится и оттестируют - сразу всё ядро планомерно перепишут на руст.

Вилами по воде виляно.

Как только ядро перепишут - большинство софта переедет с си на руст.

Опять мимо. Столько человеколет обычно ни у кого нет :)

Это может кому-то нравится или не нравится, но это произойдет

Как только, так сразу. Пока это все wishful thinking.

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

сначала пусть поищут лошьё, готовое рисковать unsafe-поделками в проде :)

slackwarrior ★★★★★
()

Пожалуй, начну читать доки по расту.

targitaj ★★★★★
()

Этот ваш раст выглядит как срр нетрадиционной ориентации. Как Иван Дулин из Челябинска который съездил в Москву и познакомился там с джава-разработчиками.

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

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

Этот ваш раст выглядит как срр нетрадиционной ориентации. Как Иван Дулин из Челябинска который съездил в Москву и познакомился там с джава-разработчиками.

Так, по-моему, может сказать человек, мало знакомый с обоими языками. По мне, так Rust очень сильно отличается от C++, причём не только в каких-то синтаксических деталях, но и концептуально.

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

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

Хорошо когда разбираешься сам, а не слушаешь местных «Карузо».

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