Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.
> I’m assuming the goal is to have the entire kernel rewritten in Rust.
Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.
> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.
If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.
It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.
char hello[5] = "Hello";
Even complex driver in rust will have very little amount of unsafe because of correct use of (often zero cost) abstractions. And it is much less mental drain to check only that, than when every single line is a minefield that could hide undefined behavior
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
charcircuit•7mo ago
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
Joel_Mckay•7mo ago
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3
leoh•7mo ago