Линус Торвальдс ответил на критику и вопросы сопровождающего ядра Linux Кристофа Хеллвига по поводу политики работы с Rust. Торвальдс заявил о неконструктивном диалоге при обсуждении интеграции кода Rust в ядро Linux и призвал сопровождающих отвечать за свой код. По мнению Торвальдся, «игнорировать сторону Rust» при работе с ядром Linux автоматически также означает, что у таких мейнтейнеров нет никакого права голоса на стороне Rust.
«Вы говорите, что не согласны с Rust — это нормально, никто никогда не требовал от вас писать или читать код Rust. Но затем вы принимаете эту позицию за то, что код Rust не может даже использовать или взаимодействовать с кодом, который вы поддерживаете. Поэтому позвольте мне быть предельно ясным: если вы как сопровождающий чувствуете, что контролируете, кто или что может использовать ваш код, ВЫ НЕ ПРАВЫ. Я уважаю вас технически, и мне нравится работать с вами. И нет, я не ищу подхалимов, и мне нравится, когда вы бросаете мне вызов. Я иногда говорю глупости, должны быть люди, которые просто выступают против меня и говорят, что я полный отстой», — пояснил Торвальдс в ответе Хеллвигу.
По поводу принятия или запрета на работу с С и Rust Торвальдс добавил, что мейнтейнерам нужно стать пластичнее и понять, что сопровождающий подсистемы может и должен знать о привязках в Rust и желать работать с кодом на стороне Rust, но, возможно, не слишком активно участвовать в этом процессе.
«Вы не можете сказать „Я не хочу иметь ничего общего с Rust“, а затем в следующем предложении сказать „И это означает, что код Rust, который я буду игнорировать, не может использовать интерфейсы C, которые я поддерживаю“. Сопровождающие, которые хотят быть вовлечены в сторону Rust, могут быть вовлечены в неё, и, будучи вовлечёнными в этот процесс, они будут иметь некоторое право голоса в том, как выглядят привязки в Rust. Они по сути также становятся сопровождающими интерфейсов Rust. Но сопровождающие, которые выбирают вариант „Я не хочу иметь дело с Rust“, тогда, очевидно, не будут беспокоиться о привязках в Rust, но в результате они также не будут иметь никакого права голоса в том, что происходит на стороне Rust. Итак, когда вы меняете интерфейсы C, разработчикам на Rust придётся иметь дело с последствиями и исправлять привязки в Rust. Это своего рода обещание здесь: есть эта „защитная стена“ (wall of protection) вокруг разработчиков C, которые не хотят иметь дело с проблемами Rust, в обещании, что им не придётся иметь дело с Rust. Но эта „защитная стена“ в основном работает в обе стороны. Если вы не хотите иметь дело с кодом Rust, вы не получаете права голоса по поводу кода Rust. Другими словами: „никто не обязан иметь дело с Rust“ не означает, что „каждый может наложить вето на любой код Rust“, — подытожил Торвальдс.Полная версия пояснения Торвальдса в оригиналеI was hopeful, and I've tried to just see if this long thread results
in anything constructive, but this seems to be going backwards (or at
least not forwards).
The fact is, the pull request you objected to DID NOT TOUCH THE DMA
LAYER AT ALL.
It was literally just another user of it, in a completely separate
subdirectory, that didn't change the code you maintain in any way,
shape, or form.
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.
Honestly, what you have been doing is basically saying “as a DMA
maintainer I control what the DMA code is used for”.
And that is not how any of this works.
What's next? Saying that particular drivers can't do DMA, because you
don't like that device, and as a DMA maintainer you control who can
use the DMA code?
That's literally exactly what you are trying to do with the Rust code.
You are saying that you disagree with Rust — which is fine, nobody has
ever required you to write or read Rust code.
But then you take that stance to mean that the Rust code cannot even
use or interface to code you maintain.
So let me be very clear: if you as a maintainer feel that you control
who or what can use your code, YOU ARE WRONG.
I respect you technically, and I like working with you.
And no, I am not looking for yes‑men, and I like it when you call me
out on my bullshit. I say some stupid things at times, there needs to
be people who just stand up to me and tell me I'm full of shit.
But now I'm calling you out on YOURS.
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 don't have to like Rust. You don't have to care about it. That's
been made clear pretty much from the very beginning, that nobody is
forced to suddenly have to learn a new language, and that people who
want to work purely on the C side can very much continue to do so.
So to get back to the very core of your statement:
“The document claims no subsystem is forced to take Rust”
that is very much true.
You are not forced to take any Rust code, or care about any Rust code
in the DMA code. You can ignore it.
But “ignore the Rust side” automatically also means that you don't
have any say on the Rust side.
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”.
Maintainers who want to be involved in the Rust side can be involved
in it, and by being involved with it, they will have some say in what
the Rust bindings look like. They basically become the maintainers of
the Rust interfaces too.
But maintainers who are taking the “I don't want to deal with Rust”
option also then basically will obviously not have to bother with the
Rust bindings — but as a result they also won't have any say on what
goes on on the Rust side.
So when you change the C interfaces, the Rust people will have to deal
with the fallout, and will have to fix the Rust bindings. That's kind
of the promise here: there's that “wall of protection” around C
developers that don't want to deal with Rust issues in the promise
that they don't have to deal with Rust.
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?
And no, I don't actually think it needs to be all that
black‑and‑white. I've stated the above in very black‑and‑white terms
(“becoming a maintainer of the Rust bindings too” vs “don't want to
deal with Rust at all”), but in many cases I suspect it will be a much
less harsh of a line, where a subsystem maintainer may be aware of
the Rust bindings, and willing to work with the Rust side, but perhaps
not hugely actively involved.
So it really doesn't have to be an “all or nothing” situation.
Ранее сопровождающий разработчик стабильной ветки ядра Linux Грег Кроа-Хартман (Greg Kroah-Hartman) привёл убедительные доводы в пользу написания новых драйверов ядра Linux на языке программирования Rust. Кроа-Хартман является ярым сторонником добавления кода на Rust в ядро Linux. Он призвал ментейнеров проекта и разработчиков писать новый код для ядра и драйверов Linux на Rust, а не на C.
Грег Кроа-Хартман утверждает, что подавляющее большинство ошибок ядра Linux вызвано «глупыми маленькими крайнимипограничными случаями в C, которые полностью исчезли в Rust» (stupid little corner cases in C that are totally gone in Rust). Он полностью согласен за постепенный переход от кодовой базы C к новому коду на Rust, где эти проблемы с безопасностью памяти и другие недостатки C невозможны.
В середине февраля Линус Торвальдс в частном порядке заявил, что продолжит добавлять в свой проект код Rust. Эти действия будут происходить несмотря на возражения многих мейнтейнеров ядра Linux против кода Rust, фактически сделав принятие Rust неизбежным для всех участников сообщества.
Источник новости: habr.com
