Every week or so there seems to be drama about some old dude shouting about how rust in the Linux kernel is bad. Given all the open hostility, is there easier way for R4L to continue their work?
Every week or so there seems to be drama about some old dude shouting about how rust in the Linux kernel is bad. Given all the open hostility, is there easier way for R4L to continue their work?
I dont think that there is another way. They are gonna have to coexist with the old guard. The problem is, they are both right. Rust is the better language, its basically made for this task, but C runs everywhere, it has a much larger userbase, and introducing a second language into a huge low level program like Linux will make it much, much harder to maintain.
Why would you say that Rust is made for low level hardware interfacing? I am generally curious.
I was only alluding to the fact that its a low level language like C, but with a more modern design and safety features, not anything specific, sorry!
I once heard that a major problem is that you have to disable or work around Rusts safety features once you write hardware interfacing code like a os kernel
Not really. While working at the OS-level can typically require ‘unsafe’ operations a core tenet of writing Rust is making safe abstractions around unsafe operations. Rust’s ‘unsafe’ mode doesn’t disable all safety checks either - there are still many invariants that the Rust compiler enforces that a C compiler won’t, even in an ‘unsafe’ block.
And even ignoring all of that, if 10% of the code needs to be written in Rust’s ‘unsafe’ mode that means the other 90% is automatically error-checked for you, compared with 0% if you’re writing C.
The “let’s rewrite it in <insert fancy new language here>” trope only works in a small project. Doing it in large-scale years-old well-maintained projects is asking for trouble (especially if there are no unit tests) and friction.
Best way forward if they so insist is to refactor small bits without interfering with the existing code-base.
I’m not sure they’re even doing that, I think the policy is that Rust code can depend on C code, but C can’t depend on Rust. So at the moment nothing can actually be rewritten in Rust, it’s only additions like new drivers.
What prevents them from rewritting old drivers? Some sort of API incompability? I was under the impression they were doing just that.
I think the biggest issue would be a lack of interfaces to the C side code, they’re slowly being fleshed out and each one enables more functionality for the Rust modules.
e.g. the test Ext2 driver a MS dev wrote last year after enough of the filesystem interfaces got hooked up
But even then, I don’t think the maintainers would accept one that replaces the existing C driver, that’d break non-Rust builds and architectures, and that’s a sure-fire way to get Linus on your case. Best you can hope for is one that complements a C driver, and even then I think you’d need a good reason to have two drivers for the same hardware.