3 ms·
>Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying anything similar? In fac
by fluoridation 2y ago
>Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying anything similar?
In fact, he said that as his very first reply to that thread:
https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/ https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c9...
>Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.
- mustache_kimono 2y ago> In fact, he said that as his very first reply to that thread: I think it's clear from the surrounding context that you are likely over-interpreting some of Hector's comments. What is the losing side of history here? There is simply too much C code in the Linux project to say "stop this ride, I want to get off and only use Rust" right now. This is a fight about some new code. Rust drivers in kernel and perhaps in the future Rust in other places it makes sense. I believe Hector's arguing Rust drivers are inevitable, because they are already here! What did I say above: > I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
- fluoridation 2y agoAs I read it, "the losing side of history" refers to insisting on using C, possibly at all. The last part about the "world moving forward towards memory-safe languages" doesn't suggest a limited scope for the statement. The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module, thus requiring being knowledgeable about both languages in order to maintain it, thus making the module less maintainable. In fact, a few developers were saying that they didn't mind Rust drivers, if they used the C ABI as-is. Someone wanted to expose new Rust-specific interfaces to support cleaner abstractions from Rust drivers.
- mustache_kimono 2y ago> The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module AFAIK this is false. The patch was CCed to the maintainer as FYI, but all the code was in a Rust a module binding to the C DMA interface. If I'm wrong, show me the code. See the discussion here: https://lkml.org/lkml/2025/1/9/398 https://lkml.org/lkml/2025/1/9/398
- fluoridation 2y agoI'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense.
- mustache_kimono 2y agoFine. But, when I say something is out in out false, it might be worth checking your facts. I'm willing to grant that it is possible Christoph Hellwig simply misunderstood the patch and overreacted. rust/bindings/bindings_helper.h | 1 + rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++ rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + 4 files changed, 274 insertions(+) create mode 100644 rust/kernel/dma.rs See: https://lkml.org/lkml/2025/1/8/801 https://lkml.org/lkml/2025/1/8/801 See: https://lkml.org/lkml/2025/1/9/398 https://lkml.org/lkml/2025/1/9/398 See: https://lkml.org/lkml/2025/1/10/619 https://lkml.org/lkml/2025/1/10/619 See: https://lkml.org/lkml/2025/1/29/999 https://lkml.org/lkml/2025/1/29/999
- dralley 2y ago>I'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense. You've now discovered why this blew up in the first place. All of the excuses used to reject the code were not just petty but also outright false, and trivially so.