From Jason Gunthorpe, maintainer of 5 Linux kernel subsystems:

IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.

Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".

(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)

I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...

Linux-for-Rust or Rust-for-Linux [LWN.net]

@lina yeah.. we really need to focus more on getting stuff merged and I'd love for nova and asahi to work together on the bindings/abstractions so we can finally get things going here. And there are people more involved and knowledgeable with drm/kms working on nova, so I'm pretty confident that we can make this work.

And if it means we use a new drm_scheduler written in rust so be it.

@karolherbst @lina would a DRM scheduler in Rust provide APIs also usable by C drivers in replacement of the bad C one ?

@Sobex @lina in theory yes. With rust you can specify the calling convention and every rust function can be compiled with the C one for compatibility.

And then you have "cbindgen" as a project to generate a C header file you simply include and link against.

The really nice think about rust is, that you don't need any kind of FFI code to call C or vice versa. Rust wrappers are really only about writing good abstractions, not about making it possible to use C code in rust or vice versa.

@karolherbst @Sobex You can write Rust that can be called from C, but you have to do that explicitly. The situation doing idiomatic Rust to C abstractions is actually worse than the other way around, because while Rust can support concepts like C struct embedding etc. (just unsafely), there is absolutely no way for C to directly interact with concepts like Rust generics. You'd have to introduce more explicit layers of abstraction in some cases with extra allocations and things like that.

And maybe that's a good thing. If we end up having high quality native Rust code in the kernel and C ends up being a second class citizen if it wants to use it, maybe that'll help convince the C people to learn Rust. We're certainly not going to degrade Rust code to C standards and design just so C people can interact with it in a C way.

@lina @Sobex oh sure, you can't map everything, but if you e.g. have a C API, you can implement that in rust just fine. And then C code can just call into rust code, which might be a better approach here than using cbindgen.
@lina @karolherbst @Sobex can you start with gccrust with the same architectural coverage? I still have phantom pains from projects stopping working because someone pulled in a dependency that wouldn't compile on perfectly capable machines, and it's starting anew with Python's Rust frenzy