[dwattttt]

It's unfortunate: a simple example is effectively all plumbing, and those would touch all the (unsafe) native interfaces.

A driver that actually does something interesting would be able to have unsafe interfaces at the boundary, and more typical Rust code inside.

[AndrewGaspar]

Yeah, I totally get that, but I suppose my argument would be is if you're going to bother writing your driver in Rust, until there are more mature Rust bindings for the OS interfaces, you might as well only write your most safety-sensitive business logic in Rust, and then write all the interfacing with the OS in C.

[gpm]

If you look at the readme they have

> wdk: Safe idiomatic bindings to APIs available in the Windows Development Kit (WDK)

And then if you look at that crate they've only implemented dbg_break, print, spinlock, and timer.

I'd take this as a sign that the bindings are a work in progress.

If you're going to write your driver in Rust... honestly I'd recommend just writing the `wdk` crate bindings you need for your driver and probably even upstreaming them. Wrapping FFI bindings in safe abstractions is usually pretty easy - but it's definitely the case that without them rust doesn't give you much.

This sample is using `wdk_sys` bindings directly without wrapping them... which is basically never the recommended way of interacting with the FFI in rust.