On Fri, Jul 19, 2024 at 6:24 PM Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> wrote: > > For these corner cases, a simple safety comment should suffice. By all means, > let's strive to push as much of the unsafe bits into the kernel crate. But, > IMHO, we shouldn’t treat Rust drivers as some unprivileged entity, they’re > also kernel code, after all. The intention has never been to forbid unsafe blocks, but rather to minimize the amount of unsafe code as much as possible. That is why mixing Rust and C in ways that make the amount of unsafe blocks increase a lot may not be the best approaches. Sometimes it may be needed nevertheless, i.e. there is no hard rule here. Relatedly, on the topic of drivers being "unprivileged" entities: anything we can do to make any code as "unprivileged" as possible (in "number of unsafe blocks" or other ways) is likely a good thing, as long as it does not detract from what actually needs to be done and is not too onerous. In other words, part of the idea of using Rust has always been trying to see how much we could tight things up while still making things work in practice. For instance, other ways to tight things up would be disallowing to call certain APIs/subsystems/... (i.e. visibility, which we will add), marking certain crates as `#![deny(unsafe_code)]` or other lints, or verification of certain properties (there are researchers looking into this). But, yeah, I agree it will be one of the interesting discussions at Kangrejos... :) Cheers, Miguel
