Re: Rust kernel policy

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

On Wed, Feb 19, 2025 at 8:34 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> a. The apparent vast gap in maturity required of Rust versus C. What is our maturity policy going to be? Otherwise we are putting a lot of burden on C maintainers which is effectively wasted of the kernel configuration pulls in even one line of Rust.
>
> This is particularly toxic given the "no parallel code" claimed in this policy document (which really needs references if it is to be taken seriously; as written, it looks like a specific opinion.)

There is no "no parallel code" in the document, and I would like a
clarification on what you mean by "toxic" here.

I tried really hard to avoid misrepresenting anything, and the
document explicitly mentions at the top that this is our
understanding, and that the policy could change depending on what key
maintainers and the community discuss. (If it is put into the kernel
tree, then that solves that.).

Anyway, I can only guess you are referring to the "Are duplicated
C/Rust drivers allowed?" point. If so, since you want references, here
is one:

    No, don't do that, it's horrid and we have been down that road in the
    past and we don't want to do it again.  One driver per device please.

    https://lore.kernel.org/rust-for-linux/2023091349-hazelnut-espionage-4f2b@gregkh/

Things evolved after those discussions, which is why I ended up
writing the "Rust reference drivers" framework that got later used for
PHY:

    https://rust-for-linux.com/rust-reference-drivers

I hope that helps the document "to be taken seriously".

Cheers,
Miguel