Re: Rust kernel policy

[Kent Overstreet <kent.overstreet@linux.dev>]

On Fri, Feb 21, 2025 at 12:42:46AM +0100, Miguel Ojeda wrote:
> 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/

I think we need a more nuanced rule there.

When you're rolling out something new of a nontrivial size, you always
want to stage the release. You don't want everyone to start using
10k-100k lines of new code at once, you want it to first hit your power
users that can debug - and maybe the new thing isn't feature complete
yet.

If a big driver is being rewritten in Rust (e.g. if we went all the way
with the nvme driver; that was one of the first prototypes) I would want
and expect that we ship both in parallel for a few cycles and make sure
the new one is working for everyone before deleting the old one.

And tends to be what we do in practice, where appropriate. blk-mq was
incrementally rolled out. No one's even contemplating ripping out
fs/aio.c and replacing it with an io_uring wrapper.

Wholesale rewrites of entire subsystems in the kernel are rare (because
we can refactor), but with Rust we'll be seeing more and more of that -
because most of the really tricky safety sandmines do occur at FFI
boundaries.