On Tue, Jul 20, 2021 at 03:21:45AM +0200, Miguel Ojeda wrote:
> On Tue, Jul 20, 2021 at 12:16 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> > I think it's not a good idea to keep these wrappers in their own
> > rust directory, they need to be distributed out into the kernel
> > everywhere they are used. We have made this mistake before
> > with OF (device tree) that started exactly like this in
> > drivers/of/*, and now I have part of the OF GPIO handling
> > and tests inside files in that directory as a consequence.

> The `rust/kernel/*` folder currently contains all the "Rust
> abstractions" that are shared by all the kernel, i.e. in the rest of
> the kernel tree we have kernel modules that are users of the
> abstractions.

> The main reasons behind this approach are that it is the simplest one
> and that it makes a clear distinction between abstractions and user
> code. In fact, code inside `rust/` has some capabilities that we do
> not allow for non-`rust/` code. For instance, `rust/*` code can use
> the C bindings and has unrestricted access to Rust unstable features
> (though we still carefully pick the ones we use, of course). This is
> not the case for "normal" Rust kernel modules elsewhere.

> Having said that, this is not set in stone or a hard requirement -- we
> can definitely split things and move them elsewhere, e.g. having a
> `gpio` crate in `drivers/gpio/`, for instance. We could still follow
> special rules for "subsystem objects".

It does feel like it'd be good to work out some system for ensuring that
subsystem maintainers have sight of any Rust work that's going on for
their subsystems rather than having that happen off in a corner without
visibility.