I'm glad Linus didn't miss that the change was just a user of the DMA code and didn't involve any changes to DMA itself. I think that very important point was overlooked in many of the responses in the original thread.
Did the other Rust devs not manage to raise the same argument, repeatedly? It comes across that there must have been a massive breakdown in communication and it's hard for me to grok why.
There continues to be a vocal contingent of commenters (both here on HN, and elsewhere) who patiently listen to one side of the argument but put no stock whatsoever in what the R4L maintainers and contributors have to say on the subject.
> Did the other Rust devs not manage to raise the same argument, repeatedly?
Here are parts of a mail from Danilo Krummrich [1] in the thread that started all of this:
> As explained previously, this component is just a user of the DMA coherent
allocator API (just like any other driver)
> Being a maintainer myself, I think it is outside the scope of a maintainer to restrict the usage of a public kernel API for a certain entity arbitrarily and / or by personal preference, which, as it appears to me, is the case here.
Emphasis is mine. This shows that the point was repeatedly raised. You can see for yourself what the response was. Besides, the only way to miss that point is to not look at the patch at all.
This title is misleading which is why Linus wrote his note.
A better title would be “Linus clarifies that maintainers can’t dictate who or what (like Rust) use their code.”
—-
Key quote:
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.
…
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.
The title is "bombastic"; yes, a slight edit, but one that changes the meaning, especially taken out of context. What he said was that if a maintainer doesn't want to deal with Rust they don't have to deal with Rust but they also don't get to tell users of the code they maintain how (or whether) to use Rust.
> If you don't want to deal with the Rust code, you get no say on the Rust code.
FWIW, I think C++ would be much better suited for the Linux Kernel than Rust, and so much easier for C developers to adopt.
Allowing C++ would lead to endless debate over exactly which subset of C++ is allowed in the kernel, and would be a pain in the ass to police.
The point of Rust is that it offers enough facilities to the programmer that you can right near-bulletproof APIs from a memory and thread safety perspective, it has momentum with a younger and enthusiastic group of developers, and it doesn't have the problem about what to allow and what not to allow to nearly the same extent. That means the potential exists for a net-reduction in time spent reviewing code for misuses of various APIs.
within the thread, H. Peter Anvin argued the same in case you're interested on reading the arguments [1], it's the same thread where greg k-h responded that was posted in here as well [2].
I'm glad Linus didn't miss that the change was just a user of the DMA code and didn't involve any changes to DMA itself. I think that very important point was overlooked in many of the responses in the original thread.
Did the other Rust devs not manage to raise the same argument, repeatedly? It comes across that there must have been a massive breakdown in communication and it's hard for me to grok why.
There continues to be a vocal contingent of commenters (both here on HN, and elsewhere) who patiently listen to one side of the argument but put no stock whatsoever in what the R4L maintainers and contributors have to say on the subject.
> Did the other Rust devs not manage to raise the same argument, repeatedly?
Here are parts of a mail from Danilo Krummrich [1] in the thread that started all of this:
> As explained previously, this component is just a user of the DMA coherent allocator API (just like any other driver)
> Being a maintainer myself, I think it is outside the scope of a maintainer to restrict the usage of a public kernel API for a certain entity arbitrarily and / or by personal preference, which, as it appears to me, is the case here.
Emphasis is mine. This shows that the point was repeatedly raised. You can see for yourself what the response was. Besides, the only way to miss that point is to not look at the patch at all.
[1] https://lore.kernel.org/lkml/Z5qeoqRZKjiR1YAD@pollux/
It was indeed brought up.
This title is misleading which is why Linus wrote his note.
A better title would be “Linus clarifies that maintainers can’t dictate who or what (like Rust) use their code.”
—-
Key quote:
The title is copied verbatim from his mail.
> 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.
(emphasis is not mine)
The other title (https://news.ycombinator.com/item?id=43123133) seems better to me even if this version is currently more popular.
I updated the title several times but I ended up just using a (almost) straight quote from the email.
The title is "bombastic"; yes, a slight edit, but one that changes the meaning, especially taken out of context. What he said was that if a maintainer doesn't want to deal with Rust they don't have to deal with Rust but they also don't get to tell users of the code they maintain how (or whether) to use Rust.
> If you don't want to deal with the Rust code, you get no say on the Rust code.
FWIW, I think C++ would be much better suited for the Linux Kernel than Rust, and so much easier for C developers to adopt.
Allowing C++ would lead to endless debate over exactly which subset of C++ is allowed in the kernel, and would be a pain in the ass to police.
The point of Rust is that it offers enough facilities to the programmer that you can right near-bulletproof APIs from a memory and thread safety perspective, it has momentum with a younger and enthusiastic group of developers, and it doesn't have the problem about what to allow and what not to allow to nearly the same extent. That means the potential exists for a net-reduction in time spent reviewing code for misuses of various APIs.
within the thread, H. Peter Anvin argued the same in case you're interested on reading the arguments [1], it's the same thread where greg k-h responded that was posted in here as well [2].
[1] https://news.ycombinator.com/item?id=43101204