The OpenNET Project / Index page

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



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

Оглавление

Поддержка Rust для ядра Linux столкнулась с критикой Торвальдса, opennews (ok), 15-Апр-21, (0) [смотреть все]

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


2. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +12 +/
Сообщение от Вован (??), 15-Апр-21, 08:10 
По фактам!
Ответить | Правка | Наверх | Cообщить модератору

195. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +1 +/
Сообщение от Аноним (195), 15-Апр-21, 12:24 
> базовая (core) библиотека Rust неделима и представляет собой один большой blob
> у команды ещё нет стратегии, как реализовать модульность

Блобы, блобы, блобы... Кто бы сомневался. Растаманы ещё только лет через 15 смогут решить эту проблему. Или у них другие цели.

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

369. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +7 +/
Сообщение от Анонимъ (?), 16-Апр-21, 01:04 
На правах растомана соглашусь с Линусом.

Паникующим аллокациям совсем-совсем не место в ядре.

Вычислениям float не место в Linux. На определённых архитектурах (ARMv8 например) вполне можно нормально работать с float на уровне ядра. Но врятли на всех. А Linux поддерживает множество архитектур. С u128/i128 довольно сложный вопрос на самом деле. Но если упростить, тут теж проблемы, что и в случае с float.

Проблема с float и широкими типами решается добавлением чего-то вроде глобального атрибутов `#[no_fpu]` `#[no_u128]` или аналога, идентичного натуральному. Ну или даже просто опций для линтера насыпать. Хотя не факт, что эти штуки можно добавить за 5 минут. Современные компиляторы сложны в конце концов.

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

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

370. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +1 +/
Сообщение от Аноним (370), 16-Апр-21, 01:31 
> Из обычного рабочего процесса целую новость слепили.

Вот посмотрим насколько затянется "рабочий процесс".

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


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

376. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  –1 +/
Сообщение от Анонимъ (?), 16-Апр-21, 02:18 
> Вот посмотрим насколько затянется "рабочий процесс".

Не особо знаком с процессами в The Kernel, но врятли это будет быстро. В идеале в этом году закончить, уже хорошо. Всёж изменения в некотором смысле фундаментальные. При этом нужны телодвижения и с точки зрения The Kernel и сточки зрения команды Rust.

> Наверно придется написать ядерный аналог stdlib

Всё уже написано.

В rust стандартная библиотека разделена аж на три части. core, alloc и std. При этом std применима исключительно в юзерспейсе (хотя на коленке можно заставить работать), а alloc требует доработки или замены на полностью отдельную либу (в контексте The Kernel). А вот core выбрасывать смысла нет. Там исключительно те штуки, которые работают без привязки к чему либо вроде аллокации. Что-то вроде builtins.

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

410. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +1 +/
Сообщение от Аноним (370), 16-Апр-21, 11:34 
>> придется написать ядерный аналог stdlib
> Всё уже написано.

Если было бы написано, то этого обсуждаемого конфуза в "рабочем процессе" не было. И обсуждались бы проблемы реализаций разных способов выделения памяти (alloc), синхронизации доступа к сложным и составным типам данных (thread) и тп.

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

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

396. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от BSA (?), 16-Апр-21, 09:21 
Проблем с большими типами вообще быть не должно. Если целевая платформа их нативно не поддерживается, то создается или библиотечный вызов, или эмуляция в месте использования. Просто то, что на языке высокого уровня это сделать сложней, например для сложения двух чисел разрядностью в 2 раза большей, чем у регистров на ассемблере надо написать две инструкции: add r1, r1, r2 и adc r3, r3, r4. А теперь попробуйте сложение с учетом переноса сделать на любимом языке высокого уровня...
Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

441. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Анонимъ (?), 16-Апр-21, 16:53 
Аналога adc может не быть на некоторых архитектурах.
Ответить | Правка | Наверх | Cообщить модератору

459. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Аноним (-), 17-Апр-21, 06:34 
> чем у регистров на ассемблере надо написать две инструкции:

add r1, r1, r2
adc r3, r3, r4
r3 -> mem[x]
Казалось бы, что может пойти не так? У апликушника, с 1 тредом - ничего :)

А что если в реальной ОС будет, допустим, так?
add r1, r1, r2
IRQ <-
   something -> mem[x].
IRQ ->
adc r3, r3, r4
r3 -> mem[x]

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

Или:
CPU1: add r1, r1, r2
CPU2: something -> mem[x]
CPU1: adc r3, r3, r4
CPU1: r3 -> mem[x]

При том -> mem[x] для больших типов еще и само по себе не атомарное и IRQ или соседний проц может вклиниться еще и вот туда.

А круто когда у вас записалось половина переменной в память, пришел кто-то и сделал что-то, имея в виду совсем не то, потом вон тот неатомарный долелал вторую половину и .. в памяти теперь чего?! Знакомьтесь - race condition. Не очень приятно - особенно дебажить его.

Можно конечно атомарные доступы форсануть, но это какой пенальти по перфомансу будет, на минуточку, если надо сделать так чтобы IRQ и другие процессоры точно туда не влезли до того как ВСЕ это сделано? В threaded апликухе вы уже можете некоторые азы прострела пяток выкусить, но в лайтовом варианте.

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

483. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Аноним (-), 17-Апр-21, 08:20 
> Ну а проблема с паниками в аллокациях решается банальным дописыванием кода. Ну
> лол, разраб показал ревьюверу прототип. Ревьювер сказал переделать. Из обычного рабочего
> процесса целую новость слепили.

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

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

507. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Noname (??), 17-Апр-21, 15:23 
А с другой стороны, Линус эти все проблемы порешал, и отправил любителей Раста за парты.
Ответить | Правка | Наверх | Cообщить модератору

588. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Аноним (-), 20-Апр-21, 17:01 
> А с другой стороны, Линус эти все проблемы порешал, и отправил любителей
> Раста за парты.

Господа из селектела стырили новость на хабрашвабру, при том по сути скопипастили, минимально изменим, и не особо то маркируя это как таковое, только в одном месте ссылку заинлайнили минимально. Копи3.14-еры наглые, да еще пиар втулили. Пфф, борзые ребята растаманы из селектела.

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

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

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




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

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