Раз уж тут так много новых людей — и особенно много тех, с кем я совершенно не знаком — пожалуй, стоит рассказать немного о себе и об этом канале.

Меня зовут Антон, я студент человек студенческого возраста и в настоящий момент я работаю программистом, по работе пишу в основном... Да, на Rust, а как вы догадались? Я люблю Rust и ненавижу примерно все остальные языки программирования. Круг моих интересов относительно широк, но на канал изливается в основном программирование (серьёзно, около половины постов с хештегом #prog). Этот канал изначально планировался как удобная свалка ссылок, материалов и #meme-ов, и... Он таковым, в сущности, и остался. В своё оправдание я могу сказать, что все статьи (выкладываемые с хештегом #article) я всегда читаю перед тем, как выложить, так что делюсь я тем, что считаю сто‌ящим своей аудитории.

Также ведение своего канала сподвигнуло меня на написание своих постов (и иногда даже перевод чужих статей), которые я выкладываю под хештегом #моё (как, впрочем, и созданные мною мемы). В их числе я хотел бы отметить:
- написание трейта, гарантирующего нулевой размер типа
- оптимизация размера итератора из стандартной библиотеки Rust (увы, не принятая)
- реализация zero-cost форматировщиков даты
- разбор различных способ реализации полиморфизма, с их достоинствами и недостатками
- эпические "Хроники замыканий" в 3 (пока что) частях: раз, два, три
- деликатный и глубокий анализ недостатков регулярных выражений

Для удобства привожу список всех хештегов на канале (может быть пополнен в будущем):

#3dcg
#abnormalprogramming
#algo
#amazingopensource
#anime
#art
#article
#bash
#bio
#blogrecommendation
#c
#cinema
#clojure
#cpp
#csharp
#db
#demoscene
#design
#dotnet
#erlang
#game
#go
#idris
#itsec
#haskell
#js
#java
#julia
#justrustaceanthings
#kbd
#life
#math
#mechanics
#meme
#menacingopensource
#ml
#mood
#music
#outoflinestorage
#parsing
#performancetrap
#php
#pixelart
#politota
#postgresql
#prog
#psy
#puzzle
#python
#quotes
#regex
#retroit
#r
#rust
#rustasync
#rustforlinux
#rustreleasenotes
#rustlib
#scala
#science
#serde
#shell
#soc
#softskills
#sql
#successstory
#suckassstory
#tips
#typescript
#video
#web
#zig

#бомбёжкипост
#культурнаяпрограмма
#лингво
#моё
#право
#трудовыебудни

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

Добро пожаловать на канал!

#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) сишные функции и пачку связанных с этими функциями флагов.

#rustforlinux #suckassstory

(link)

I no longer have any faith left in the kernel development process or community management approach.

Apple/ARM platform development will continue downstream. If I feel like sending some patches upstream in the future myself for whatever subtree I may, or I may not. Anyone who feels like fighting the upstreaming fight themselves is welcome to do so.

Гектор Мартин (Hector Martin), ведущий разработчик Asahi Linux, снял с себя полномочия мейнтейнера поддержки железа ARM и Apple

#rustforlinux

Дальнейшие события:

Линус 19 февраля в треде с обсуждением политики ядра насчёт кода на Rust ответил на комментарий Кристофа и указал на неадекватное поведение:

I find it distressing that you are complaining about new users of your code, and then you keep bringing up these kinds of complete garbage arguments.

<...>

So this email is not about some "Rust policy". This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how.

<...>

You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".

<...>

But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code.

Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".

See?

24 февраля Andreas Hindborg послал серию патчей, которые добавляли Rust-интерфейс для configfs. В числе получателей был указан и Кристоф Хэллвиг, который поддерживает в том числе и эту подсистему.

Ответа от него в этом треде не было: в тот же день он удалил себя из списка сопровождающих dma-mapping и configfs. При этом совсем из разработки ядра он не уходит: он всё ещё остаётся сопровождающим нескольких других подсистем.

Детский сад, ей-богу.