Re: Rust kernel policy

[Kent Overstreet]

On Wed, Feb 19, 2025 at 03:59:27PM +1000, Dave Airlie wrote:
> On Wed, 19 Feb 2025 at 11:00, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> >
> > On 2/18/25 14:54, Miguel Ojeda wrote:
> > > On Tue, Feb 18, 2025 at 10:49 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> > >>
> > >> I have a few issues with Rust in the kernel:
> > >>
> > >> 1. It seems to be held to a *completely* different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.
> > >
> > > Our minimum version is 1.78.0, as you can check in the documentation.
> > > That is a very much released version of Rust, last May. This Thursday
> > > Rust 1.85.0 will be released.
> > >
> > > You can already build the kernel with the toolchains provided by some
> > > distributions, too.
> > >
> >
> > So at this point Rust-only kernel code (other than experimental/staging)
> > should be deferred to 2034 -- or later if the distributions not included
> > in the "same" are considered important -- if Rust is being held to the
> > same standard as C.
> 
> Rust is currently planned for non-core kernel things first, binder,
> drivers, maybe a filesystem,
> There will be production kernel drivers for new hardware shipping in
> the next few years, not 2034 that will require rust to work.

If we can ever get the bindings merged, I want to start using Rust in
bcachefs yesterday. I'm already using it in userspace, and already have
Rust bindings for the core btree API.

Initially it'll just be for the debugfs code so that we can test things
out on a non critical component (make sure the toolchain works, make
sure the distros aren't screaming too much).

But the sooner I can switch to writing new code in Rust, the better.

Re: compiler requirements, all this stuff is driven by practical
considerations. No one is shipping a 10 year old Rust compiler, and as
distros have become more modern and better at shipping updates there
won't ever be any reason to.

Rewriting some ancient driver that people use on ancient machines with
ancient distros would be a problem, so we won't do that.

What the actual toolchain stability requirements end up looking like in
10 years is anyone's guess (Will gcc-rs become mainstream? Will llvm
start supporting the necessary architectures? Will we just not care as
much about niche architectures? How will distros be at shipping
updates?) - so we can't say with any degree of certainty what the long
term policy will be.

But I'm sure we'll be talking to all the relevant users and stakeholders
and coming up with something reasonable.