Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).

To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.

The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.

If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?

Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.

"design your driver like amdgpu to make it work, or else"

Which is concerning, because the amdgpu driver isn't even that good. I can't tell you how many times back when I had an AMD gpu I got a system lockup because of Ring Timeouts. Meanwhile on my Intel Arc, I haven't had a *single* gpu driver crash since I got it, while with AMD it was a weekly occurance

Sensitive content Click to open/close

a few weeks ago I considered rewriting atcphy in rust because that would’ve been more fun but then stumbled across exactly that: it’s been over a year and there still wasn’t any platform device binding upstream. I would’ve been fine writing phy bindings but there‘s still a lot of infrastructure missing unfortunately :(

(Not that it matters much for atcphy: the driver doesn’t gain anything from rust since it’s fairly simple and doesn’t even need any memory allocation outside of probe. It just would’ve been more fun than rewriting the current C version to me)

Every time I am forced to look at a large C codebase I see not only a gigantic pile of nightmares, I see a gigantic pile of nightmares created by people that refuse to accept the flaws of their tools and refuse attempts to change them.

To hear that Linux is the same is unsurprising but saddening at the same time.

Ugh.

Wanting the "perfect API" is the trick these anti-Rust people use to stall things... ;;

Like they think it's the Rust team's job to fix the existing lifetime/recounting messes of the kernel before they're allowed to introduce safe APIs... even though an imperfect Rust abstraction that leaks some unsoundness in corner cases (due to underlying C problems or design) is still better than literally no Rust code at all and writing more C code...

this brings back memories of a couple of us early Rust netdev folks trying to push for a branch where we would be allowed to experiment and share abstractions that just did not have any user yet, but could be improved and reworked by people who eventually picked them up for use. It took multiple hours-long meetings to finally ending up agreeing that we would just all share links to our respective code and pray that anymore who wasn't aware of it wouldn't have to reinvent the wheel again abstraction-wise.

I don't want to fall into tribalism, or paint all C (or even netdev) developers as stuck-up assh*les, far from that, but it's clear that the requirements imposed on Rust developers to adhere to the way things have always been done in C, and effectively considering Rust as a guest who should be grateful to be in the project, rather than a system capable of making informed decisions about other systems*, places a ton of constraints that just make our development harder and slows down the inertia to get the project to mature. Meanwhile, a lot of time has to be spent by the heads of the project (bless them) doing diplomacy because otherwise patches don't get reviewed, and C devs don't see our point.

Plus the random stubborn and very opinionated dude every now and then of course, but it's the linux dev community, ofc it'll happen.

• (eg. Rust being used must not motivate large changes on the C side, Rust has to reproduce the way things are done in C however bad they are etc)