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

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

что значит «портировали Rust для ядра»? Никто никуда никого не портировал. Просто имеется некоторые проблемы с тем как обрабатывать панику в ядерном коде, у Линуса мнение что, от нее надо избавляться, в общем-то флаг в руки как тут было неоднократно подмечено, нехай пишут на голом rust без любого кода который может породить панику или вообще продолжают писать на С. Линус как обычно воспламеняется на ровном месте.

Ты читаешь оф доку стандартной библиотеки, которая подразумевает наличие ОС под ней. А вот тебе оф дока раста, которая подразумевает что ОС нет, и там нет вектора https://doc.rust-lang.org/core

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

Надо полагать, что у всех только Intel и только последнего поколения. Других процессоров и архитектур нет.

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

что значит «портировали Rust для ядра»?

это значит сделали возможным писать код для ядра на Rust

Никто никуда никого не портировал

всё намного хуже - в LKML обсуждение, а так да - сидели бы лучше отдельным форком на гитхабе, кому надо пусть и пишет на Rust

В рамках Ц/ЦПП я всегда получу что-то валидное, которое вписывается в рамки стандарта.

Чего? Какого стандарта? Мы говорим о языке, который в ядре уже используется и о его стандартных возможностях, с которыми в ядро нельзя. Т.е. прямой контрпример твоему высказыванию.

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

Но если ядро захочет, то оно спокойно будет экспортировать символы malloc и printf.

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

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

Ты подозреваешь, что в компиляторе Раста нет проверки, существует ли вызываемая функция в подключенных библиотеках?

Вообще-то возвращает. А наличие исключений ты не заметил.

Не возвращает. Не, есть nothrow, конечно, но и у Раста есть try_new и try_reserve, но если ты настаиваешь на обычном идиоматическом коде как из юзерспейса, то и в плюсах никаког null ты не получишь. И исключения - это, извини, не то, это фактически та же паника.

Всё что нужно Расту для попадания в ядро - реализация panic, которая сообщит ядру о том, что данный модуль не справился и его надо прибить. Без паники совсем нельзя: у Раста контроль выхода за границы. Далее, логично что нужна адаптация вектора. В принципе можно взять уже существующий, убрать из него reserve, заменить вызовы reserve внутри на panic!, и оставить try_reserve(). Да, это будет слегка другой вектор, в котором перед работой нужно оценить необходимый размер и вызвать try_reserve и обработать ошибку. Аналогично для других контейнеров

• Ой, раст решит утечку и сегфолты… срочно запретить!

это значит сделали возможным писать код для ядра на Rust

Расскажите что же такого сделали с rust чтобы это стало возможно, и было невозможно до того как это сделали?

всё намного хуже - в LKML обсуждение, а так да - сидели бы лучше отдельным форком на гитхабе, кому надо пусть и пишет на Rust

о чем и речь, никто ничего с rust не делал, просто у Линуса есть вопросы к rust в виду специфики работы кода ядра. Другое дело, что он сам в этом же посте и написал что все это опасения не основе предположений. Если честно вся эта новость яйца выеденного не стоит, никаких фундаментальных ограничений для того чтобы писать код ядра в rust нет, но в виду специфики работы ядра, придется отказаться от любого кода который может породить панику, и написать что-то более сиподобное.

У меня были не совсем верные представления. Я сейчас накатил раст, скомпилил хелоу ворлд с вектором, оказывается, ваши бинари юзают libc и malloc из него (правда мой вектор все равно заооптимизировался, хотя давал опцию -C opt-level=0, но malloc все равно дернулся для чего-то).

Я просто где-то читал: «смотрите как прекрасно, у раста нет рантайма». Подумал, что его стд полностью самодостаточная. А зависимостей у растового хелоу ворлда даже больше, чем у плюсового.

Расскажите что же такого сделали с rust чтобы это стало возможно, и было невозможно до того как это сделали?

с растом пока ничего не делали - делают с ядром

91 files changed, 11080 insertions(+), 45 deletions(-)

с растом скорей всего тоже будут что-то делать

On floating-point, 128-bit, etc.: the main issue is that the core library is a single big blob at the moment. I have already mentioned this to some Rust team folks

никаких фундаментальных ограничений для того чтобы писать код ядра в rust нет

осталось хоть один полезный драйвер увидеть на расте

Судя по всему ты не понимаешь о чём говоришь… точнее ты свои фантазии на тему (ну или по крайней мере свои представления) выдаёшь за некоторые факты. В разрезе того, что предложенный драйвер на Rust’е вообще никакого отношения не имеет к железу, то твоя отсылка к оному выглядит достаточно смешной.

с растом пока ничего не делали - делают с ядром

91 files changed, 11080 insertions(+), 45 deletions(-)

с растом скорей всего тоже будут что-то делать

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

осталось хоть один полезный драйвер увидеть на расте

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

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

Of course! What happens here is that we use, for the moment, `alloc`,
which is part of the Rust standard library. However, we will be
customizing/rewriting `alloc` as needed to customize its types (things
like `Box`, `Vec`, etc.) so that we can do things like pass allocation
flags, ensure we always have fallible allocations, perhaps reuse some
of the kernel data structures, etc.

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

Паранойю всё-таки стоит поумерить. Делают внешний (по отношению к ядру) раст-интерфейс к ядерным функциям, а не что-то куда-то впихивают поглубже.

Нет, ты писал глупость и продолжаешь писать глупость. Они же пишут, что будут подгонять/переписывать alloc под реалии ядра. Это значит что они отвяжут реализацию вектора от malloc и сделают возможным использование вместо него kmalloc, vmalloc, etc. Что тебе в этом не нравится, что они хотят тощий враппер, с набором типовых операций?

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

std в ядро не примут по очевидным причинам, да и не нужно оно там.

Блин, ну понятно, что в ядре будет дергаться kmalloc вместо malloc, я ведь о том и толкую - закостылить интерфейс для стд раста, вместо всяких функций из libc. Я ведь с самого начала про вектор говорил, но меня стали убеждать, что все не так и в драйверах его использовать не будут.

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

Изначальный тезис звучал иначе. В этом и дело что ядро подтюнят под rust

не знаю каких ты тезисов наслушался, но это очевидно из названия рассылки - LKML

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

We will need a way to «cut» some things out, for instance with the «feature flags» they already have for other crates (or they can split `core` in to several, like `alloc` is for similar reasons). Or we could do it on our side somehow, but I prefer to avoid that (we cannot easily customize `core` like we can with `alloc`, because it is tied to the compiler too tightly)

не факт что только на стороне ядра, но на это как раз мне лично пофиг

Блин, ну понятно, что в ядре будет дергаться kmalloc вместо malloc, я ведь о том и толкую - закостылить интерфейс для стд раста, вместо всяких функций из libc. Я ведь с самого начала про вектор говорил, но меня стали убеждать, что все не так и в драйверах его использовать не будут.

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

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

Мда. Ещё одна глупость. Напоминаю про «stable API nonsense» от Линуса Грега, что ядро плевать хотело на внешний мир и будет ломать совместимость со всем, что не является его частью. Это уже весомая причина что-то тащить в ядро, а не быть отщепенцем снаружи.

не знаю каких ты тезисов наслушался, но это очевидно из названия рассылки - LKML

Так ваших же тезисов, вы сказали что rust портировали для ядра, а на самом деле, на rust и С пишут изменения@дополнения к ядру чтобы использовать rust. Сам rust никто не меняет.

не факт что только на стороне ядра, но на это как раз мне лично пофиг

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

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

Это Ваше мнение. А реалии таковы, что надо менять.
Или дальше жуём Си.

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

Да потому что для раста это как мертвому припарка. Вот объясни такое - мы пишем модуль для ядра, у нас аллокаторы на kmalloc и все такое (буду на цпп, сути не меняет):

...
vector v{1, 2, ...};
v.push_back(4);
...

и вот в одной из этих операций нам не дали память, как ты узнаешь об этом внутри модуля?

Написав

struct AllocError<T>(T);

impl<T> Vec<T> {
    fn push(item: T) -> Result<(), AllocError<T>> {
        /* ... */
    }
}

// -------------

match vec.push(item) {
    Ok(()) => {
        /* allocation was successful */
    },
    Err(AllocError(item)) => {
        /* allocation failed */
        do_something_else_with_item(item);
    }
}

Сишникам можно, растовикам нельзя. Так и запишем.

И т.е. нужно лишь свой аллокатор, а саму стд допиливать не надо? Жаль, если так.

А если создаешь вектор:

let vec ... [...]

то тоже можно ошибку получить в случае чего?

Т.е. вектор из alloc Rust (Которую ты почему-то зовёшь std, хотя это не одно и то же) похож на вектор из std C++. И вот этот вот вектор из alloc собираются взять и подрихтовать, что бы он идеально вписывался в реалии ядра, в частности - имел обработку ошибок с выделением памяти. При этом версия alloc, которую сделают в ядре НЕ_БУДЕТ совместима ни с версией alloc, которую используют прикладные программы, ни с std, которая используются в юзерспейсе.

Для жаль не вижу повода.

Судя по всему ты не понимаешь о чём говоришь…

Да понимаю я, в ядре просто не хотят много регистров сохранять/загружать при переключениях.

откуда у вас такие познания о ядре win16

в японии до сих пор используют?

Это не является валидным синтаксисом.

Если ты видел странную конструкцию let foo = vec![1, 2, 3, 4];, то это макрос, который разворачивается в:

let foo = {
    let items = [1, 2, 3, 4];
    let mut vec = Vec::with_capacity(4);
    vec.extend(IntoIter::new(ITEMS));
    vec
};

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

Заранее скажу что let items = [1, 2, 3, 4]; - это массив фиксированной длины, выделенный на стеке.

Вот так правильно.

let foo = {
    let items = [1, 2, 3, 4];
    let mut vec = Vec::with_capacity(4);
    vec.extend(IntoIter::new(items));
    vec
};

так они же уже написали каких то костылей с паникой, с обещаниями в будущем, если бы да кабы, либо выплюнуть свой core либо rust будет предоставлять конфигурацию для выбрасывания неугодной функциональность. Сдается мне, все останется на подобного рода костылях https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git/+/refs/tags/next-20210415/rust/compiler_builtins.rs

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

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

откуда у вас такие познания о ядре win16

Ради интереса разбирался. Даже свой анализатор и дизассемблер NE модулей делал т.к. не нашёл существующих.

Жесть, как вы там живете )). Про Ц говорят, что намешают этих макросов так, что не понять что к чему, а у вас там на ровном месте макросы. Отладка там вообще боль, наверное.

занимаетесь системным программированием?

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

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

Не сам Rust, а alloc - одна из его библиотек. Эта минорная заморочка ничей пыл не охладит. Видел бы через какой они адок прошли на разных этапах - знал бы.

Кому как, как по мне - очень даже ахти. Жалуются в основном те, кто ни разу на нём не писал.

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

Раст и так был не ахти с виду, а сейчас к нему ещё 100500 проверок в коде добавится.

Проверок будет не больше чем в сишке, но писать их будет проще. Не if (bla(&val) == -1) goto cleanup; , a let val = bla()?;

Сдается мне что все что будет связано с rust он вообще читать не будет и оставит спасение утопающих утопающим, потому что это интерес определенного круга лиц, по сути этот интерес нужен только им и они и работают над возможностью написания чего-либо для ядра на rust. В общем-то вряд ли Линус пустит rust дальше «предбанника».

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

Да вроде там есть вариант не включать SIMD, но использовать их, вручную сохраняя стек. Хз как там с планированием в ядре, но если прерывания процесса извне нету, то можно 128 и никаких проблем с context switch.

soft-float что ли, что-то такое. В том смылсе, что конпиль это сделает сам.

Ну не удивил, в Си тоже макросы есть:

#define LET(type, name, val) type name=val; if(!name) goto cleanup

После Раста я понял насколько красив и лаконичен Ц/ЦПП.

в Си тоже макросы есть:

А как же do { /* stuff */ } while (0)

После Раста я понял насколько красив и лаконичен Ц/ЦПП.

M4. Который можно использовать везде, но почему-то никто не хочет, «как ни странно».

Хочешь объявить внутри цикла? Кто-то будет это так использовать:

if (...)
   LET(int, var, fn());
else
   ...

А если и будет, то получит ошибку компилции

Напоминаю про «stable API nonsense» от Грега, что ядро плевать хотело на внешний мир и будет ломать совместимость со всем, что не является его частью. Это уже весомая причина что-то тащить в ядро, а не быть отщепенцем снаружи.

Как-то понял только с точность до наоборот. Цитата была про ВНУТРЕННИЕ API ядра. К внешнему API позиция прямо противоположная - не ломать ни в коем случае (ну только ессли случай совсем безысходный, тогда обсуждаемо).

Но то, что в коде идёт после cleanup: придётся писать ручками в каждой функции.

Ну можно функцию нужную, так что нет. А у вас аборт(), наверное?)) В любой непонятной ситуации надо падать )