Re: [RFC PATCH 1/5] doc: rust: create safety standard

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Fri, Jul 19, 2024 at 6:24 PM Daniel Almeida
<daniel.almeida@collabora.com> 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