Comment by lousken
3 days ago
I wonder how Microsoft implements rust in their kernel.
As for this issue, it's just a nature of any project, people will come and go regardless, so why not let those C developers leave and keep the rust folks instead? At some point you have to steer the ship and there will always be a group of people unhappy about the course
From what I can tell, Microsoft seems to have the advantage that a lot of in-kernel interfaces are documented and relatively stable. Linux guarantees that the userland APIs don't change, but when a kernel component changes you're out of luck. Windows seems much more focused on internal consistency and stability. Probably in part because a lot of proprietary software uses a lot of internal APIs not meant for public consumption and there's nothing Microsoft can do to stop that, really.
In a way, these Rust bindings are somewhat stabilizing the Linux API as well, by putting more expectations and implications from documentation into compiler-validated code. However, this does imply certain changes are sure to break any Rust driver code one might encounter, and if may take Rust devs a while to redesign the interfaces to maintain compatibility. It's hardly a full replacement for a stable API.
At the moment, there aren't enough Rust developers to take over kernel maintenance. Those Rust developers would also need to accept giant code trees from companies updating their drivers, so you need experts in both.
With the increasing amount of criticism languages like C are receiving online because we now have plain better tooling, I think the amount of new C developers will diminish over the coming years, but it still may take decades for the balance to shift.
or they can be adults and work it out. Sometimes you just ahve to put the kids in different sandboxes and keep them apart, that's why we have APIs and calling conventions.
Microsoft allows C++ in the kernel too, but what I'm wondering how SEH would be handled there. For example reading from user provided memory that maybe invalid, you need "__try/__catch" there.
https://github.com/microsoft/windows-drivers-rs/blob/main/ex...
hum - yeah - https://github.com/microsoft/windows-drivers-rs/issues/6
Alternatively, there's nothing preventing the Rust folks building their own kernel from the ground up.
There are multiple kernels written in Rust already. Writing another one wouldn't be interesting.
The point of R4L is that people want to write drivers for Linux in Rust. The corporate sponsors that are involved also are interested in writing drivers for Linux in Rust. Sure, Google could rebase Android on top of RedoxOS or Fuschia and Red Hat could spend a decade writing Linux Subsystem for RedoxOS, but neither want to do those things. They want to write drivers, for Linux, in Rust.
Telling them to write a new kernel is a bit like telling them they should go write a new package manager. It's a completely different thing from what they actually care about.
[flagged]
3 replies →
The kernel is not a problem. Drivers are. If it wasn’t for drivers we’d all be rolling our own custom kernels.
MBA moment