LINUX.ORG.RU

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

 , ,


2

4

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

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

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

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

>>> Источник

anonymous

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

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

Если в ядре появятся x86 принтеры, будет печально.

AVL2 ★★★★★ ()

Торвальдс полагает, что первоначальной областью применения rust в ядре могут быть драйверы

Глубочайше заблуждение. Ну ему надо было для пацанов что-то сказать. Мдааааа.

После того, как отодвинули его с помощью дочки от дел, сломался Линус. Теперь только и пишет, что «посмотрим».

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

После того, как отодвинули его с помощью дочки от дел, сломался Линус.

А можно описать ситуацию для тех кто был в коме?

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

Предсказуемый адекватный ответ адекватного человека. Очень хорошо.

Он очень, ОЧЕНЬ ругал ЛЮБЫЕ попытки всунуть другой языкв разработку ядра. У него была чёткая, жесткая позиция. Теперь нет. Если не умеешь в С - не лезь! А дальше он матами.

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

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

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

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

https://900913.ru/note/b/linus-weekend/
https://dou.ua/forums/topic/25085/

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

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

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

mimico ()

Sylvestre Ledru, a Mozilla director by day and Debian Linux developer by night,

пипец красноглазик

has ported a Rust version of Coreutils to Linux using the LLVM compiler infrastructure and its Clang C language front-end and tooling infrastructure

Кхм… а coreutils это вот прямо самая актуальная часть опенсорса для перевода на rust, которая прям таки погибает из-за «thread safety and prevent memory-related errors»? У кого-то ls сегфолтит каждую неделю? Мне казалось, эти утилиты наоборот, самые вылизанные и пофикшенные. Т.е. вот как бы переписал coreutils на rust, а профит где?

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

Вот пусть писатели дров на расте и дописывают их каждый раз.

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

сейчас есть python2, python3 в системе, а будет rust100, rust129, rust143, rust150, и каждый нужен для сборки своего особенного драйвера. :)

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

Нет, он по-прежнему ясно высказывает свою позицию по некоторым вопросам (например ещё раз про C++ из недавнего «…a braindead language that isn’t relevant to the kernel.»). В данной ситуации видимо он понимает, что растописатели всё равно пропихнут раст в ядро, так что лучше не сопротивляться, а сделать всё правильно и безболезненно для окружающих (не можешь остановить – возглавь!)

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

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

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

Он очень, ОЧЕНЬ ругал ЛЮБЫЕ попытки всунуть другой языкв разработку ядра. У него была чёткая, жесткая позиция. Теперь нет.

Раньше не было другого языка кроме С, который бы удовлетворял его критериям языка, пригодного для разработки ядра. Теперь, видимо Rust к этим критериям приблизился. Уже есть на что смотреть.

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

Ого, какие люди

Раньше не было другого языка кроме С, который бы удовлетворял его критериям языка, пригодного для разработки. Теперь, видимо Rust к этим критериям приблизился. Уже есть на что смотреть.

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

Иначе разработка такого крупного проекта как ядро превратится в настоящий ад.

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

Си стандартизован? Там существует десяток стандартов.

Попробуйте собрать современным компилятором пример 20-летней давности (я уж не говорю про K&R диалект), и результат будет скорее всего примерно тот же, что с Rust-ом двухлетней давности. А ядру-то уже более 20 лет. Поэтому разница с высоты четвертьвековой истории ядра уже не принципиальна.

vitus ()
Ответ на: Ого, какие люди от wandrien

Мне казалось, что Rust после выхода Rust 1.0 довольно неплохо поддерживает совместимость в рамках editions. Разве есть какие-то реальные примеры безопасного (в смысле sound) кода пятилетней давности, который сейчас не компилируется с --edition 2015 ? (Я не исключаю, что он есть, ибо сам в теме не особо разбираюсь)

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

Попробуйте собрать современным компилятором пример 20-летней давности

Достаточно регулярно этим занимаюсь.

Проблемы обычно на уровне API, иногда на уровне того, что авторы кода не увидели UB. На уровне языка — никогда.

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

Если в ядре появятся x86 принтеры, будет печально.

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

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

Попробуйте собрать современным компилятором пример 20-летней давности

Я тут недавно скомпилял flex 2.3.7 с помощью gcc 10.2, полёт нормальный.

А потом с помощью 16-битной версии ACK, ещё проприетарной, правда пришлось порезать буфера, иначе 64 килобайт не хватает.

luke ★★★★★ ()

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

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

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

И правильно делал. Си стандартизован.

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

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

На уровне языка - это прямо манна небесная. Меняю любой UB на ошибку компиляции

На ошибку компиляции, потому что поменяли семантику? Ну-ну.

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

В том числе. Что угодно лучше тихого UB проходящего тесты.

vertexua ★★★★☆ ()

Насыщенной и интересной жизнью начинаем жить, уважаемые красноглазики. Это событие века, не меньше

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

Ручное управление памятью нужно искоренять, никакие правильные практики не спасают от человеческого фактора.

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

А вот постоянный код вида:

int baz()
{
	//...
	mutex_lock(m);

	ret = foo1();
	if (ret<0)
		goto out;

	ret = foo2();
	if (ret<0)
		goto out;

	ret = foo3();
	if (ret<0)
		goto out;

	ret = foo4();
	if (ret<0)
		goto out;

	ret = foo5();

out:
	mutex_unlock(m);
	return ret;
}

надоедает очень быстро. Плюс читается очень медленно.

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

Если не умеешь в С - не лезь!

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

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

например memcpy() имеет UB при пересекающихся областях откуда и куда.

Но вот в таком коде это на момент компиляции невозможно обнаружить в общем случае:

uint8_t *src = get_source_addr(...);
uint8_t *dst = get_destination_addr(...);
memcpy(dst, src, LENGTH);

cvs-255 ★★★★★ ()
Ответ на: комментарий от seiken

Вот пусть писатели дров на расте и дописывают их каждый раз.

Писатели дров их и так каждый раз дописывают. подсистемы ломают чаще чем раст.

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

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

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

ну т.е. unstable, помноженный на unstable, «они нашли друг друга»

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

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

Это ты каким образом понял? Откуда такая информация?

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

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

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

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

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