@delroth I love how he keeps on bringing up RHEL but Asahi *is* the reason why Fedora is turning on Rust in distro kernels now. I'm pretty sure that's doing more to push RHEL to do that eventually than anything else.

Also there are literally companies investing in Asahi these days, just not ones who care about RHEL. But I guess he thinks only RHEL matters and anything else is "a toy" even though one such company has roughly ~the same market cap as RH did before the IBM acquisition today.

@delroth @lina i paid almost a thousand for a high-end AMD GPU, and have been plagued by IRQ kernel panics due to a memory safety bug *affecting several generations of hardware* that is still going unfixed for over *6 months after reporting*.

causing me lost data, wasted evenings on recompiling kernels instead of playing with friends and hours of annoyed rebooting.

and the "unmerged, tiny, niche, non-commercially-relevant" driver is doing better?
well, that should be humiliating, lmao.

@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.

@Sobex @karolherbst Probably not easily if written in idiomatic Rust with stuff like generics. I certainly don't plan to spend time thinking about that right now. It'd just be part of the driver, and if Nova wants to share it we'll move it to common Rust code.

Though you can always make wrappers work some way, so perhaps we could task the C people with writing C abstractions to the Rust scheduler if they really want to use it. Let them suffer the cross-language adaptation pain for once...

@Sobex @karolherbst @lina All problems are solvable, Rust even has macros (IMHO crappy but still better than CPP).

There's but one problem, and its name is 'rustc'.

Rustc architecture coverage (in supported and regularly tested form) is nowhere close providing for still used platforms in Linux kernel. Using Rust for Apple Silicon drivers is fine because ARM64 is supported. Using it for API common across all platforms is a problem.

@lina ... laid out by POSIX and the GNU applications. Basically, runs these apps and you have instant value. Only once Linux reached feature parity with, say, SunOS did it start to seriously extend the feature space.

Redox seems IMO a bit too eager to reinvent the whole world and that will make it a niche effort.