Как стать автором
Обновить

Комментарии 29

Что такое "правила времени"?

Очевидно, библиотеки (RTL).

Гугл транслейт такой транслейт…
«lifetime rules» — видимо правила управления временем жизни переменных и прочего. Не понятно подружится ли код ядра Linux и правила владения\времени жизни из Раста.

Управление временем жизни надо полагать. В rust есть возможность такое указать для некоторых штук.


Например возьмём динамический массив в куче. Потом берём ссылку на один из элементов массива. И мы можем доказать, что ссылка на элемент массива не переживёт сам элемент массива. А самое главное — это проверяется на этапе компиляции. Это важно, поскольку если у нас получится невалидная ссылка, то она в какой-то момент может указывать не только на другой элемент, но и вообще на не связанную с массивом память.


Это лишь простой пример, но это работает для всего в Rust.

Я знаю про lifetime rules в Rust, но тогда остается загадочной фраза "правилами времени, написанными на C"

Сама концепция lifetime существует вне контекста Rust. Равно как и проблемы, связанные с несоблюдением этих штук. В Rust просто есть возможность проверять это всё на этапе компиляции.

В расте «правила времени» заложены в основу языка. Си же не накладывает никаких ограничений, так что разработчики ядра линукс изобрели свои методы и правила. Мистер Хартман говорит, что успех раста в ядре линукс в основном зависит от того, как эти два подхода удастся подружить.
Растоманы заявляют что rust спасет всех от ошибок, связанных с памятью, но за 4 года не могут пофиксить свой redox и идут ломать линукс.
Не помню, чтобы утечка памяти входила в класс ошибок, которые Rust обещал отлавливать.
Эмм, а владение в Rust'е разве не об этом?

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


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


С другой стороны, создать ссылку на невалидный (неинициализированный или уже освобождённый) участок памяти в безопасном подмножестве раста не получится. Такой код просто не скомпилируется

Если Вы храните коллекцию с неиспользованными данными — это не утечка данных, это просто неоптимальный по памяти код. А вот если Вы объявляете коллекцию удаленной или теряете на нее все ссылки, не освободив при этом память — это называется утечкой, и в безопасном Rust'е это вроде как невозможно.
Циклические ссылки, например, вполне возможны (и не освобождаются никогда).
это называется утечкой, и в безопасном Rust'е это вроде как невозможно

Конечно возможно. Есть даже специальный метод для этого — https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak

С другой стороны, создать ссылку на невалидный (неинициализированный или уже освобождённый) участок памяти в безопасном подмножестве раста не получится. Такой код просто не скомпилируется

Правда?

Нет. Была даже эпичная история с утечкой, вызванной библиотечным кодом, не помеченным unsafe, вследствие чего комитет сделал вывод, что утечка не является критичным с точки зрения безопасности состоянием, и даже убрал ансейф с метода явной утечки mem::forget.

Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees in the same way that disallowing data races at compile time is, meaning memory leaks are memory safe in Rust.

doc.rust-lang.org/book/ch15-06-reference-cycles.html
и пример модуля ядра с драйвером символьного устройства


Всего одна строчка оттуда:
let data = Pin::from(Box::try_new(unsafe { Mutex::new(0) })?);

Что в этой строчке особенного, что вы её так выделили?

Для rust — пожалуй, ничего
а зачем там unsafe?

Потому что Mutex::new() — unsafe. А он unsafe, потому что после new() и перед использованием надо обязательно вызвать init() — который тоже unsafe, потому что сгенерирован из кода на Си и ещё не обёрнут.

Это другой Mutex — kernel::sync::Mutex.

Синтаксис языка похож на Си и C++;
копия на Осях нет возможности превзойти
квантовый язык возможно конкурент Си++
Линус Торвальдс рассказал о том, где Rust впишется в Linux
«Линус Торвальдс согласился, что можно проверить обещания rust на драйверах, от которых ничего не зависит».
Вне контекста эту формулировку можно понять несколько иначе — будто Линукс говорит о драйверах, на судьбу которых всем плевать. Правильнее оно звучит в контексте.
Первая цель для Rust — это драйверы просто потому, что там вы найдете множество различных возможных путей реализации

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


То бишь, в цепочке зависимостей драйверы находятся на самом краю и с точки зрения рефакторинга это проще всего. Что значит будущее linux ядра это переписывать драйверы на rust, а основные подсистемы оставить на С. Может быть когда-нибудь дойдут руки переписать и их.
Вне контекста эту формулировку можно понять несколько иначе — будто Линукс говорит о драйверах, на судьбу которых всем плевать
этого я конечно же не подразумевал. Я сетую на то, что заголовок натянуто-додуманный и что журналистика в общем всё дальше и дальше скатывается из донесения фактов в продажу фальсификаций.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.