It'd be really exciting if they make a safe Rust API for kernel drivers. You can technically write a driver in Rust, but the bulk of your code will be interacting with the unsafe, complex C API, so it's a bit pointless.
One could make the same point about any rust that ultimately interfaces with the system using libc - all Rust programs at one point were interfacing with a lot of C code.
A more serious counter argument is that Mozilla did exactly this with Rust in Firefox - and it seems to be a success, there's still lots of Rust in the browser and it seemingly is working.
Point being, using Rust for all of the things will probably be painfully cumbersome today, but writing up a complicated enough component with a well defined boundary with the rest of the kernel will probably prove immensely useful and won't be painfully cumbersome.
And that unsafe, complex C API communicates with an even sketchier system made of registers, IO ports and nasty hardware details. Providing a higher level API for a nastier backend has always been a core feature of operating systems and programming languages.
Almost nothing is still I/O ports because it's more portable to use MMIO and if you're going to offer MMIO why bother also doing I/O ports. But yes, as a vague outline you're correct.
WIL is user mode, for applications. Drivers will use Kernel Mode Driver Framework or User Mode Driver Framework. UMDF has a COM style API.
C++ has been usable in the Windows kernel for a long time but you need to make sure that code ends up in the correct PE segment types for pageable and non pageable code and that there are no hidden gotchas for features like exception unwinding and that new can use paged or non paged pool appropriately. Same for Rust: getting to a nostd etc that is compatible with kernel use.
I think there’s a strong case that many drivers could be written with either a user mode driver framework or a small VM. Most of the hardware devices I’ve worked with we just need fast transfers of data to user mode buffers so our application can handle it, and the code is mostly boilerplate framework code plus setting up device registers to set up DMA transfers. I don’t see why that couldn’t be handled with say an EBPF or WASM equivalent byte code.
> wil was primarily developed by the Windows shell team for writing usermode code, but the NDIS and Bluetooth teams have contributed some small kernel-specific features. Here's a few examples of how you can use wil in your kernel driver:
You'd need some kind of formal model of the hardware for that to be feasible. A big part of doing driver development is writing strings of bits to hardware addresses over I2C, SPI, USB or other protocols.
