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)

@argv_minus_one @raulinbonn The Linux kernel uses no_std. Until recently there was an internal fork of the alloc crate with those fallible constructors outright gated off. Now things are switching to custom allocators where the Box types (there are several to allow for different allocators in the kernel) are outright always fallible with the standard constructors.

lore.kernel.org/lkml/202408160…

> the maintainer blocked it and said I should just do "what other drivers do".

The maintainer must have been haunted by Grace Hopper after that.

youtube.com/watch?v=si9iqF5uTF…

I'm not going to touch the existing DRM scheduler, I'm just going to write my own that is part of the driver. If Nova wants to use it we'll figure out how to make it common Rust code. C drivers can continue to use the broken C one that's already there, and fight the brokenness themselves.

The DRM scheduler is helper code, it's not a core part of the DRM subsystem. You can simply choose not to use it and roll your own. Half of DRM is like this.

(Nova is the new Nvidia driver, and yes, it's written in Rust, so Rust will be mandatory for open source upstream support of new Nvidia GPUs. That's already decided.)

I have seen the same situation in fs realms too, some "not-so-polite" MM guys want to improve their work and pushing new interfaces to fses.

But the main objective of the maintainer for any fs, is to keep their fs working without regression. So migrating to newer interface is not the priority and will only happen gradually.