|
This is a fair and much more complete engineering assessment.
The current work demonstrates that Rust can provide strong safety boundaries for important low-level mechanisms, but it does not imply that the broader NT architecture has been solved. IRP cancellation and completion races, wait objects, paging constraints, DMA, object lifetimes, PnP, power management, and compatibility with existing drivers all require far more elaborate protocols and state machines.
Rust can encode some of those rules more explicitly through types, ownership, reference counting, pinned objects, capability-style APIs, and restricted state transitions. For example, paged and nonpaged allocations or operations permitted at particular IRQLs could potentially be represented by distinct types. But Rust cannot automatically prove the correctness of the full asynchronous protocol, external driver behaviour, hardware interaction, or every cancellation race.
So I agree with the distinction: nanokrnl is an impressive proof of concept and its current abstractions are valuable foundations, but they should not be interpreted as evidence that a complete, compatible, and safe NT kernel follows easily. The real research and engineering question is how much of NT’s historically informal discipline can be converted into enforceable abstractions while keeping the remaining "unsafe" core small, explicit, and auditable.
|