The OpenNET Project / Index page

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



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

Оглавление

Для ядра Linux предложен драйвер GPIO, написанный на Rust, opennews (ok), 20-Июл-21, (0) [смотреть все]

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


55. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +14 +/
Сообщение от Аноним (55), 20-Июл-21, 17:11 
Конкретный код про выделение памяти с обработкой ошибки выделения на си занимает 2 строки (выделил, сверил указатель с null), на Rust это какая-то дикость
```
Ref::try_new_and_init(
            device::Data::new(
                PL061Registrations {
                    gpio_chip: gpio::ChipRegistration::default(),
                },
                PL061Resources {
                    base: IoMem::try_new(res)?,
                    parent_irq: irq,
                },
                // SAFETY: We call `irqsave_spinlock_init` below.
                unsafe { IrqDisableSpinLock::new(PL061Data::default()) },
            ),
            |mut data| {
                // SAFETY: General part of the data is pinned when `data` is.
                let gen = unsafe { data.as_mut().map_unchecked_mut(|d| d.deref_mut()) };
                kernel::irqdisable_spinlock_init!(gen, "PL061::General");
            },
        )?;
```

По сути и там и там это про управление памятью, только в си оно прямое, а в Rust тебе приходится делать то же самое, но косвенными путями, с болью и мучениями. Читать такой код и понимать, что конкретно он будет делать с памятью - очень сложно, это задача из разряда "а если бы вот ты знал особенности компилятора Rust, ты бы написал лямбда-функцию и итератор вместо простого new с присваиванием, и производительность бы выросла в 1000 раз". Нужна предсказуемость, пожалуйста.

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

71. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Аноним (76), 20-Июл-21, 17:25 
Тут код в основном про безопасную инициализацию, а не про выделение памяти. лямбды иногда пихают для ленивой инициализации, но это общий для многих языков паттерн
Ответить | Правка | Наверх | Cообщить модератору

79. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (55), 20-Июл-21, 17:31 
Код-то в основном про инициализацию, но именно этот неделимый на более мелкие куски блок кода, над результатом которого выполняется оператор ?, теоретически способен вернуть какую-нибудь информацию об ошибке при аллокации.
Ответить | Правка | Наверх | Cообщить модератору

87. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –3 +/
Сообщение от НяшМяш (ok), 20-Июл-21, 17:40 
Ну вообще вот это написано чисто из-за ядерной специфики.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

92. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (55), 20-Июл-21, 17:48 
Отлавливать ошибки аллокации было бы неплохо и в userspace-приложениях, тем более раз уж Rust пытается быть безопасным как в рекламе, а не безопасным от двух багов - use-after-free и double-free
Ответить | Правка | Наверх | Cообщить модератору

157. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Ordu (ok), 20-Июл-21, 21:19 
> Отлавливать ошибки аллокации было бы неплохо и в userspace-приложениях, тем более раз
> уж Rust пытается быть безопасным как в рекламе, а не безопасным
> от двух багов - use-after-free и double-free

У тебя есть use-case для отлова ошибок аллокации в userspace-приложениях? По-моему опыту в linux'е без oom-killer'а, лишь бы сдохли все побыстрее, кто выжрал столько памяти. Если когда они продерутся через всё это и дождутся NULL в качестве результата malloc, ещё вот не хватало, чтобы они пытались бы провести какой-то рекавери после ошибки. Пускай ДОХНУТ суки.

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

229. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Аноним (55), 21-Июл-21, 03:37 
Ну например если бы программа или игрушка при вылете написала, что она вылетела из-за недостатка вот такого конкретного количества оперативной памяти, а не просто паникнула с кашей в консоль, это было бы очень полезно знать конечному пользователю. Сразу ясно, что тут нужно освободить или докупить памяти, а не ругаться на разработчиков со словами "ваша штука сама вылетает без какой-либо вменяемой информации" и удалять эту программную гадость, неспособную даже объяснить, что конкретно ей не понравилось, в чем ошибка.
Ответить | Правка | Наверх | Cообщить модератору

231. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Ordu (ok), 21-Июл-21, 04:05 
> Ну например если бы программа или игрушка при вылете написала, что она
> вылетела из-за недостатка вот такого конкретного количества оперативной памяти, а не
> просто паникнула с кашей в консоль, это было бы очень полезно
> знать конечному пользователю.

Такого количества это какого? Программа выделяет себе хрена в ступе арену, чтобы потом не кучей общего назначения пользоваться, а чтоб побырому оттуда объекты фиксированного размера выделять? Ну дык ты эту арену всё равно будешь писать ручками, запрашивая память не у кучи, а через mmap. Вот там и обработаешь все ошибки. Вернёшь Result если хочется няшно, или прям оттуда сделаешь panic!("You have not enough memory, moron! Go buy some more of it!").

Или программа выделяет понемногу из кучи, и потом память кончается? Это закончится тем, что у тебя вся система подвиснет, и ты будешь ругаться на разработчиков, что они тебе систему повесили. Если у тебя хватит терпения дождаться, то может ты в консоли что-то и увидишь, а скорее не хватит и ты в PowerOff тыкнешь на системном блоке.

Не, я так думаю, стандартный интерфейс к памяти -- это не для игроманства, игре нужен ограниченный real-time, который может быть разломан swap'ом легко. Надо опрашивать систему на предмет того, сколько есть свободной памяти, неплохо было бы защитить страницы от свопирования (я не знаю, если честно, возможно ли это в linux без рутовских прав?), бла-бла-бла... Не, стандартная куча не для тебя. Тебе надо свой alloc писать -- реализацию кучи можно взять на стороне, но вот проверку доступной памяти, предвыделение её, прибивание гвоздями к физической раме -- это стандартная куча не умеет. Надо вручную запиливать эти возможности в кучу. Можно прям в std'шную реализацию. Можно в какую ещё по вкусу. Можно вообще выкинуть слово куча из лексикона, и заменить аренами и памятью на стеке.

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

242. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (55), 21-Июл-21, 08:32 
вышеописанная ошибка при выделении памяти для арены не теряет свою актуальность

память можно выделять как угодно, это же си, делай как тебе надо!

своп кстати можно отключить, если при его использовании всё так виснет грустно.

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

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

295. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –2 +/
Сообщение от Ordu (ok), 21-Июл-21, 14:20 
> вышеописанная ошибка при выделении памяти для арены не теряет свою актуальность

Возьми такой крейт с реализацией арены, который будет об этих ошибках сообщать. Проблем-то. Или напиши свой, сообщающий.

> своп кстати можно отключить, если при его использовании всё так виснет грустно.

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

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

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

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

258. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Совершенно другой аноним (?), 21-Июл-21, 09:52 
> неплохо было бы защитить страницы от свопирования (я не знаю, если честно, возможно ли это в linux без рутовских прав?)

man mlock

Если я правильно понял - пишут, что для непривилегированных процессов есть soft limit RLIMIT_MEMLOCK.

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

412. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноньимъ (ok), 24-Июл-21, 04:07 
В линуксе даже кеш фс не могут от свопа защитить...
Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

416. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от n00by (ok), 24-Июл-21, 07:35 
А зачем? Когда юзеры добровольно организуют своп в zRAM))
Ответить | Правка | Наверх | Cообщить модератору

417. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноньимъ (ok), 24-Июл-21, 08:44 
> А зачем? Когда юзеры добровольно организуют своп в zRAM))

Тем более за этим.

Но да, одно изобретение линукса чудесатее другого.

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

256. "Для ядра Linux п.редложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Michael Shigorinemail (ok), 21-Июл-21, 09:28 
> Если когда они продерутся через всё это и дождутся NULL
> в качестве результата malloc

Это вообще когда при overcommit-то?

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

193. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –6 +/
Сообщение от Аноним (193), 20-Июл-21, 23:15 
У Си с его malloc и проверкой на NULL (ага, NULL, а не null) есть маленькая проблемка. Веделенная память содержит "мусор", т.е. неизвестный набор байт и язык Си не проверит за программиста, не забыл ли тот корректно инициализировать все поля. Без такой инициализации в дальнейшем может прилететь.

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

Что-то типа https://ru.scribd.com/document/403214728/Modern-Memory-Safet..., только бесплатно

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

227. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +3 +/
Сообщение от Аноним (55), 21-Июл-21, 03:29 
Ваша ссылка вывалила мне кучу рекламы и предложила купить какие-то курсы, а если не куплю - то и читать мне она ничего не даст. Что касается инициализации - берешь структуру (в си есть структуры) и инициализируешь, это ведь делается одинаково что в Rust, что в Си. Можно даже свой конструктор написать, где объединяется выделение памяти и инициализация, получится всё по RAII. А если надо - пишешь геттеры и сеттеры, при правильной работе с типами в Си компилятор Си тоже не даст записать в структуру мусор. Все-таки в си есть свобода - можно писать так и эдак, можно работать с типами и подсказками компилятора, а можно сказать компилятору что разберешься без него и все переменные сделать void* . В Расте же ты гвоздями прибит к его способу работы с ресурсами и данными, это может быть где-то удобно, но не везде, например что если я хочу использовать четыре разных аллокатора памяти? Или написать свой собственный? А вот как в расте написать свой Vec с ручной работой с памятью через unsafe, например хочу чтобы сначала заполнялись четные ячейки массива, а потом нечетные, или чтобы в Vec были куски, при доступе к которым вываливалась бы ошибка (в ядре такое есть, чтобы выявлять доступ куда-то не туда, т.е. баги при работе с памятью)?  На Rust я такое не смогу, а на си - достаточно просто. А Zig так вообще практически из коробки дает возможность гибкой работы с аллокаторами (функции принимают аллокатор как аргумент).
Ответить | Правка | Наверх | Cообщить модератору

228. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +4 +/
Сообщение от Аноним (228), 21-Июл-21, 03:34 
для склеротиков есть calloc
Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

232. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Ordu (ok), 21-Июл-21, 04:12 
calloc не инициализирует, а обнуляет. Разницу объяснять надо?
Ответить | Правка | Наверх | Cообщить модератору

283. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +2 +/
Сообщение от z (??), 21-Июл-21, 13:44 
Вообще-то по стандарту именно "The space is initialized to all bits zero". Реально же есть интересные нюансы https://vorpus.org/blog/why-does-calloc-exist/
Ответить | Правка | Наверх | Cообщить модератору

275. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Аноним (278), 21-Июл-21, 13:06 
memset(ptr, 0, sizeof(...));
это ясен пень, и такое забывать нельзя.
Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

287. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от z (??), 21-Июл-21, 13:53 
malloc + memset != calloc см. хороший разбор на линке выше.
Ответить | Правка | Наверх | Cообщить модератору

298. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –2 +/
Сообщение от Совершенно другой аноним (?), 21-Июл-21, 14:48 
К сожалению там почти всё "заблюрено". Единственный плюс у calloc() относительно malloc(), это защита от переполнения при умножении числа элементов на размер элемента.
Ответить | Правка | Наверх | Cообщить модератору

300. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +2 +/
Сообщение от z (??), 21-Июл-21, 14:55 
Там еще разные скорости и разные внутренние политики. Позвольте еще раз привести https://vorpus.org/blog/why-does-calloc-exist/ - последний параграф как раз об этом.
Ответить | Правка | Наверх | Cообщить модератору

310. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Аноним (278), 21-Июл-21, 15:46 
В микроконтроллерах STM32 такого нет. Как и zeromem.
Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

312. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (278), 21-Июл-21, 15:47 
calloc есть оказывается, попутал.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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