4 ms·

> 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 H

> 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 ago
As 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 ago
    I'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense.
    - mustache_kimono 2y ago
      Fine. 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.

fluoridation 2y ago

As 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 ago
  I'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense.
  - mustache_kimono 2y ago
    Fine. 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.