Notice: file_put_contents(): Write of 19166 bytes failed with errno=28 No space left on device in /var/www/tgoop/post.php on line 50

Warning: file_put_contents(): Only 4096 of 23262 bytes written, possibly out of free disk space in /var/www/tgoop/post.php on line 50
Блог*@dereference_pointer_there P.9180
DEREFERENCE_POINTER_THERE Telegram 9180
#rustforlinux #suckassstory

TL:DR: Тем временем в Linux один активный долбоёб мейнтейнер Christoph Hellwig активно мешает #Rust for Linux.

DMA (Direct memory access) — технология, предоставляющая (относительно) прямой доступ к RAM для периферии. Это позволяет процессору управлять IO с устройствами асинхронно, не блокируясь на каждую операцию ввода-вывода. Использование DMA позволяет серьёзно повысить быстродействие системы в целом, а для, скажем, видеокарт и сетевых карт это и вовсе практически обязательная вещь из-за объёма обмениваемых данных.

Разумеется, в Linux есть свой API для DMA. По понятным причинам его используют практически все драйвера. Для того, чтобы сделать Rust for Linux практичным, нужно предоставить доступ к DMA для кода на Rust, и соответствующий патч от 8 января 2025 года именно это и делает. В нём добавляется минимально необходимый для использования код: RAII-обёртка над выделенными регионами памяти, операции для записи и небезопасная операция для чтения (почему unsafe? Потому что соответствующий метод read предоставляет доступ к выделенной памяти, как неизменяемый растовый слайс, и это пользователю API нужно удостовериться, что, пока слайс жив, железо не меняет данные под слайсом и тем самым не вносит UB).

Первым же ответом от Кристофа Хэллвига — человека, который отвечает за DMA в Linux — было "No rust code in kernel/dma, please". Да, это ответ целиком. Эта претензия абсолютно необоснована — достаточно взглянуть на первые строчки diff-а, чтобы понять, что меняется лишь растовый код, а не сишный в kernel/dma.

Последующий тред показал, что Кристоф абсолютно против существования растовой абстракции над DMA в любом виде, причём без предоставления внятных технических аргументов.

Скажем, вот как диалог пошёл после первого ответа:

(Miguel Ojeda): > What do you suggest?

> Keep the wrappers in your code instead of making life painful for others.

(Danilo Krummrich): > What does "your code" mean? Duplicated in every driver? Otherwise rust/kernel/dma.rs seems reasonable, no?

> Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.

Последующий обмен сообщениями показал, что Кристоф, судя по всему, считает, что этот код делает Linux многоязычным и потому автоматически плохим. Замечания от мейнтейнеров R4L о том, что никто не ожидает от Кристофа, что он будет заниматься поддержкой растового кода, ни к чему не привели. Сообщения Кристофа содержали такие занимательные цитаты:

(link)
If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).


(link)
Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this.
<...>
I do not want it [Rust — прим. моё] anywhere near a huge C code base that I need to
maintain.


(link)
> I do acknowledge your reservations about the possible maintenance burden
> due to the introduction of a rust (or another language) consumer of the
> dma-api. But I was hoping that we could arrive at some sort of common
> ground?

The common ground is that I have absolutely no interest in helping
to spread a multi-language code base. I absolutely support using
Rust in new codebase, but I do not at all in Linux.


Для понимания масштаба неадекватности претензий: R4L уже существует довольно продолжительное время, причём в транке, по понятным причинам там уже есть приличное количество абстракций над API ядра, а патч, с которого и начался весь сыр-бор, оборачивает один (1) сишный тип, две (2) сишные функции и пачку связанных с этими функциями флагов.
🤡3513🤬6👍2👎1🎉1



tgoop.com/dereference_pointer_there/9180
Create:
Last Update:

#rustforlinux #suckassstory

TL:DR: Тем временем в Linux один активный долбоёб мейнтейнер Christoph Hellwig активно мешает #Rust for Linux.

DMA (Direct memory access) — технология, предоставляющая (относительно) прямой доступ к RAM для периферии. Это позволяет процессору управлять IO с устройствами асинхронно, не блокируясь на каждую операцию ввода-вывода. Использование DMA позволяет серьёзно повысить быстродействие системы в целом, а для, скажем, видеокарт и сетевых карт это и вовсе практически обязательная вещь из-за объёма обмениваемых данных.

Разумеется, в Linux есть свой API для DMA. По понятным причинам его используют практически все драйвера. Для того, чтобы сделать Rust for Linux практичным, нужно предоставить доступ к DMA для кода на Rust, и соответствующий патч от 8 января 2025 года именно это и делает. В нём добавляется минимально необходимый для использования код: RAII-обёртка над выделенными регионами памяти, операции для записи и небезопасная операция для чтения (почему unsafe? Потому что соответствующий метод read предоставляет доступ к выделенной памяти, как неизменяемый растовый слайс, и это пользователю API нужно удостовериться, что, пока слайс жив, железо не меняет данные под слайсом и тем самым не вносит UB).

Первым же ответом от Кристофа Хэллвига — человека, который отвечает за DMA в Linux — было "No rust code in kernel/dma, please". Да, это ответ целиком. Эта претензия абсолютно необоснована — достаточно взглянуть на первые строчки diff-а, чтобы понять, что меняется лишь растовый код, а не сишный в kernel/dma.

Последующий тред показал, что Кристоф абсолютно против существования растовой абстракции над DMA в любом виде, причём без предоставления внятных технических аргументов.

Скажем, вот как диалог пошёл после первого ответа:

(Miguel Ojeda): > What do you suggest?

> Keep the wrappers in your code instead of making life painful for others.

(Danilo Krummrich): > What does "your code" mean? Duplicated in every driver? Otherwise rust/kernel/dma.rs seems reasonable, no?

> Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.

Последующий обмен сообщениями показал, что Кристоф, судя по всему, считает, что этот код делает Linux многоязычным и потому автоматически плохим. Замечания от мейнтейнеров R4L о том, что никто не ожидает от Кристофа, что он будет заниматься поддержкой растового кода, ни к чему не привели. Сообщения Кристофа содержали такие занимательные цитаты:

(link)

If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).


(link)
Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this.
<...>
I do not want it [Rust — прим. моё] anywhere near a huge C code base that I need to
maintain.


(link)
> I do acknowledge your reservations about the possible maintenance burden
> due to the introduction of a rust (or another language) consumer of the
> dma-api. But I was hoping that we could arrive at some sort of common
> ground?

The common ground is that I have absolutely no interest in helping
to spread a multi-language code base. I absolutely support using
Rust in new codebase, but I do not at all in Linux.


Для понимания масштаба неадекватности претензий: R4L уже существует довольно продолжительное время, причём в транке, по понятным причинам там уже есть приличное количество абстракций над API ядра, а патч, с которого и начался весь сыр-бор, оборачивает один (1) сишный тип, две (2) сишные функции и пачку связанных с этими функциями флагов.

BY Блог*


Share with your friend now:
tgoop.com/dereference_pointer_there/9180

View MORE
Open in Telegram


Telegram News

Date: |

Ng, who had pleaded not guilty to all charges, had been detained for more than 20 months. His channel was said to have contained around 120 messages and photos that incited others to vandalise pro-government shops and commit criminal damage targeting police stations. Clear The initiatives announced by Perekopsky include monitoring the content in groups. According to the executive, posts identified as lacking context or as containing false information will be flagged as a potential source of disinformation. The content is then forwarded to Telegram's fact-checking channels for analysis and subsequent publication of verified information. Your posting frequency depends on the topic of your channel. If you have a news channel, it’s OK to publish new content every day (or even every hour). For other industries, stick with 2-3 large posts a week. On Tuesday, some local media outlets included Sing Tao Daily cited sources as saying the Hong Kong government was considering restricting access to Telegram. Privacy Commissioner for Personal Data Ada Chung told to the Legislative Council on Monday that government officials, police and lawmakers remain the targets of “doxxing” despite a privacy law amendment last year that criminalised the malicious disclosure of personal information.
from us


Telegram Блог*
FROM American