The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 6.1, opennews (?), 12-Дек-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


327. "Релиз ядра Linux 6.1"  +/
Сообщение от Аноним (333), 13-Дек-22, 08:15 
Этот так называемый системный язык даже не способен на автоматические биндинги к си. Поэтому недалеким растоманам приходится оборачивать структуры ядра в растобиндинги вместо того чтобы сразу писать на ANSI C
Ответить | Правка | Наверх | Cообщить модератору

335. "Релиз ядра Linux 6.1"  –1 +/
Сообщение от Аноним (160), 13-Дек-22, 08:51 
> растоманам приходится оборачивать структуры ядра в растобиндинги

Это наводит на мысль, "внезапно", что структуры в расте - не просто структуры, а с излишней нагрузкой. Но растаманы хвастались, что выхлоп раста - zero-free-runtime, идентичный Си.

Ответить | Правка | Наверх | Cообщить модератору

359. "Релиз ядра Linux 6.1"  –1 +/
Сообщение от Аноним (333), 13-Дек-22, 12:05 
А растоманы готовы бить себя четырьмя пятками в грудь что у них zero-free-runtime
На самом деле у них one-free-runtime
Ответить | Правка | Наверх | Cообщить модератору

354. "Релиз ядра Linux 6.1"  +1 +/
Сообщение от фф (?), 13-Дек-22, 11:05 
ну дык пусть оборачивают - это же проблема программиста модуля и его компилятора. Можно даже генератор какой-то написать, если руками лениво.
на выходе то почему нельзя сделать стандартный модуль со стандартными биндингами к стандартным структурам ядра? Эдак можно дойти до того, что прогрмаммам написанным на расте нужна будет особая операционка для их запуска.
Ответить | Правка | К родителю #327 | Наверх | Cообщить модератору

367. "Релиз ядра Linux 6.1"  +/
Сообщение от Аноним (160), 13-Дек-22, 13:07 
> прогрмаммам написанным на расте нужна будет особая операционка

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

Ответить | Правка | Наверх | Cообщить модератору

395. "Релиз ядра Linux 6.1"  +1 +/
Сообщение от llolik (ok), 13-Дек-22, 19:04 
> Этот так называемый системный язык даже не способен на автоматические биндинги к си.

А bindgen - это тогда что, я не понял? https://docs.rs/bindgen/latest/bindgen/
Примерная схема, как всё устроено (ссыль исключительно из-за картинок): https://habr.com/ru/company/ruvds/blog/670748/

> Поэтому недалеким растоманам приходится оборачивать структуры ядра в растобиндинги вместо того чтобы сразу писать на ANSI C

Как я понял, идея в том, чтобы переписать рантайм без libc (на структурах ядра) и по максимуму абстрагировать там же весь unsafe, чтобы уже в конечных драйверах его уже использовать по-минимуму (в идеале, не использовать совсем) и, соответственно, полагаться на гарантии safe-rust. К слову у unsafe тоже есть гарантии, но несколько более слабые (ссыль на русском https://doc.rust-lang.ru/book/ch19-01-unsafe-rust.html )

Ответить | Правка | К родителю #327 | Наверх | Cообщить модератору

399. "Релиз ядра Linux 6.1"  +/
Сообщение от Аноним (-), 13-Дек-22, 19:58 
> Как я понял, идея в том, чтобы переписать рантайм без libc

Мимо. Нет никакого рантайма. Про рантайм начали говорить опеннетовские сишники, и прекратили говорить примерно тогда, когда им объяснили что если _это_ рантайм, то в си _этого_ рантайма больше, чем в любом расте.

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

У раста есть огромный компайлтайм. Ооо, его уменьшили, когда добавили параметризовать типы числами, а до этого макросами генерили имплементации для всех размеров слайсов с 0 до 32. 33 имплементации. И это только слайсы. Уж не знаю, как они там с &str выкручивались, также наверное? А diesel, ты не пробовал его компилять под таблички с 64+ столбцами? Я имею в виду до того, как параметризация значениями стала доступной. Сейчас стало лучше, но я заверяю тебя, в компайл тайме там очень много чего есть. А вот в рантайме только то, что использовал.

> по максимуму абстрагировать там же весь unsafe

Уже теплее. Но недостаточно точно.

Демаркация safe/unsafe -- это не обязательно абстракция. Абстракции могут быть накладны. C'шные строки, например, могут выйти боком, если писать на расте и этих строк много, потому что раст прежде чем работать со строками хочет убедиться, что они utf8 строки, и он не парится насчёт терминирующего нуля. Преобразовывать туда-сюда строки то ещё удовольствие.

Safe-обёртки над C нужны не для того, чтобы создать новые абстракции, а чтобы записать C'шные абстракции на расте, включая сюда и всё то знание об этих абстракциях, которые в C'шном варианте существует только в документации к API или даже только в коллективном бессознательном. Все те гласные и негласные правила о том, как API можно или нельзя использовать, должны быть описаны в самом API, чтобы попытка использовать его неправильно кончалась бы ошибкой компиляции. Например, memcpy нельзя вызывать на двух пересекающихся областях памяти, так? Но это никак не отражено в заголовке memcpy, об этом только в документации к memcpy можно вычитать. В расте это недопустимо: неправильное использование memcpy может привести к повреждению памяти, значит memcpy должен иметь такой заголовок, чтобы его можно было бы использовать только правильно.

На этом бы всё может и кончилось бы, но ядро имеет довольно вычурные правила когда и что можно, а когда и что нельзя, и тут собственно и начинается самое интересное. С преогромным любопытством я наблюдаю, как растоманы выкручиваются, и сейчас я думаю, стоит ли начинать делать ставки на то, что в дополнение к safe/unsafe демаркации, они добавят что-нибудь типа environment's, с возможностью описывать правила, как функции объявленные в одном environment можно вызывать из другого environment'а. Наверное пока не стоит делать ставок, потому что я не додумал мысль до конца, и не уверен что она удачная.

Ответить | Правка | Наверх | Cообщить модератору

403. "Релиз ядра Linux 6.1"  +/
Сообщение от llolik (ok), 13-Дек-22, 20:38 
> У раста есть огромный компайлтайм

Ок. Не буду спорить, глубоко в тему не закапывался. Гуру Раста себя не считаю, кодил на нём пока не особо много. Было интересно, чего все так пригорают с синтаксиса. Причину возгораний не понял до сих пор: синтаксис, как синтаксис / язык, как язык, не самый плохой.

> Safe-обёртки над C нужны не для того, чтобы создать новые абстракции, а чтобы записать C'шные абстракции на расте ... и т.д.

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

> Наверное пока не стоит делать ставок, потому что я не додумал мысль до конца, и не уверен что она удачная.

Как-то вот тоже, прочитал, задумался. Подумал, что может и не будут выкручиваться. Из серии: мы вам давали гарантии memory safety на уровне языка, вот они, а "вот это вот: туда ходи, туда не ходи" мы не договаривались, "тут наши полномочия, всё" (с).

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру