4 ms·
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 interacti
by TillE 3y ago
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.
- pjmlp 3y agoIt doesn't change the point being made in regards to safety, however Windows kernel drivers nowadays tend to use C++, not C. There is even a template library for it, Windows Implementation Libray, WIL.
- becurious 3y agoWIL 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.
- pjmlp 3y agoWIL is used on the kernel by some teams. https://community.osr.com/discussion/291326/the-new-wil-library-for-c-code-in-drivers https://community.osr.com/discussion/291326/the-new-wil-libr... > 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:
- martin8412 3y agoYou'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.
- None4U 3y agoMaybe on the hardware side, but the way we communicate that to Windows can still be under Microsoft's control
- eptcyka 3y agoOne 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.
- nikanj 3y agoAnd 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.
- tialaramex 3y agoAlmost 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.
- bpye 3y agoAlmost nothing has to use IO ports. Things like PCI config space accesses can still be done over IO ports though.