193
Linus responds to Hellwig - "the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL... if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG." (lore.kernel.org)
submitted 2 years ago by to c/linux@programming.dev
41 comments fedilink hide all child comments
 

Hellwig is the maintainer of the DMA subsystem. Hellwig previously blocked rust bindings for DMA code, which in part resulted in Hector Martin from stepping down as a kernel maintainer and eventually Asahi Linux as a whole.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 years ago (12 children)

Theprimeigen covers the drama very effectively and their are some good technical arguments on both sides.

  • permalink
  • fedilink
  • source
  • hideshow 12 child comments
    •
  • [–] 35 points 2 years ago (11 children)

    So far, the only good argument I have really seen from the ones opposing the Rust4Linux effort comes down to: adding Rust to a C codebase introduces a lot of complexity that is hard to deal with.

    But the argument offers no solution except to give up and not even attempt to address the real issues the kernel struggles with. It’s effectively a form of defeatism when you want to give up and don’t want to let others attempt to do what you don’t see as feasible.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 7 points 2 years ago (10 children)

    I don't know I think the argument about forcing maintainers to learn Rust is probably true - sure the Rust code might not touch the DMA code, but Linux doesn't have stable APIs so in theory you're supposed to be able to change an API as long as you fix all the drivers that use it.

    That now involves fixing Rust drivers, so you're going to need to know Rust.

    However I don't think that's a good reason not to do it. In my opinion Linus should just be honest and say that the Rust experiment has been successful, Rust is going to be part of the kernel moving forwards, and you will probably have to get off your arse and learn it.

    All this "you won't have to learn Rust" talk is thin reassurance to keep people happy. I don't think anyone really believes it.

    Reminds me of when WASM was introduced and everyone was saying "the goal isn't to replace JavaScript" to keep the JavaScript folk happy, despite everyone knowing that that was exactly the goal.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 26 points 2 years ago (8 children)

    That now involves fixing Rust drivers, so you're going to need to know Rust.

    The R4L approach is that C maintainers never need to touch any Rust code. They can break it all day long without paying any attention to it. This has been an essential part of the project from the start, I don't understand how people talking about this topic still don't understand this.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 8 points 2 years ago (1 child)

    Last time around Asahi Lina (major contributor to the Apple Silicon GPU driver) made a very nice writeup on mastodon about her attempts to mainline her work.

    Part of the problem was that the C interface was straight-up broken; not only were a bunch of lifetimes undocumented, but freeing the kernel objects properly was impossible, but GCC doesn't care and neither did anyone because GPU drivers are expected to just... never exit (IIRC). So she refactored it to be saner.

    Anyway apparently it was rejected for much the same reasons, aka Rust bashing thinly disguised as concerns over maintainability.

    Technically the R4L project did have an impact. But what's the worst case? Spending some time on improving the C interface for an edge case? The ignominy! NAK.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 years ago (5 children)

    I do understand that that's what they claim. I just don't believe them. Because it requires either

    1. magical Rust maintainers who are always on call to help, or
    2. people to be on with the Rust code breaking all the time.

    Neither seems likely.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 2 years ago (4 children)

    What's there not to believe? If Rust gets broken, either someone will fix it, or the kernel releases with broken Rust. Where's the issue?

    It's such a strange position to take.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] -1 points 2 years ago (3 children)

    or the kernel releases with broken Rust

    This is what I don't believe. I think what will actually happen (or could at least), is:

    C dev that refuses the learn Rust: "Hi, here's a change to the DMA API."

    Linus: "Can you fix the Rust code before I merge this?"

    C dev: "Ok, Rust devs it's your job - can you fix it?"

    Rust devs: ""

    C dev: "Hello? Where are you?"

    ...

    C dev: "Can we just merge it now?"

    Linus: "No we need to fix the Rust."

    Again, to be 100% clear, I think that this shouldn't block Rust. We should just expect the C devs to learn a bit of Rust (seriously if they're writing Linux DMA systems they are easily bright enough to do it). But pretending that they won't have to to keep them happy seems disingenuous.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 2 years ago* (2 children)

    Okay? And why are you imagining things would go down like that, when the policy is specifically not doing it this way? When this issue hasn't occurred so far?

    Rust is disabled by default, so it's not like it would be harder to build a kernel when it's broken. Seriously, I just don't get why you're imagining these things.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 2 years ago (1 child)

    And why are you imagining things would go down like that

    Because I am familiar with human behaviour.

    Rust is disabled by default

    I'm not too familiar with Linux's CI system but I assume they at least test that it compiles, even if it is disabled by default.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 2 years ago

    Because I am familiar with human behaviour.

    Human behavior doesn't dictate that a Linux kernel with failing Rust builds wouldn't get published.

    I’m not too familiar with Linux’s CI system but I assume they at least test that it compiles, even if it is disabled by default.

    Yes, the systems would notice that something broke. Those systems have no say in whether something gets released.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 15 points 2 years ago

    That now involves fixing Rust drivers, so you’re going to need to know Rust.

    I also don’t think the latter follows from the former. You can continue to not know Rust as long as you’re willing to work with those that can. Problems only start if you’re unwilling to collaborate.

  • permalink
  • fedilink
  • source
  • parent