Re: [LSF/MM/BPF TOPIC][RESEND] Status of Rust in the block subsystem

[Miguel Ojeda]

On Tue, Mar 17, 2026 at 8:18 AM Hannes Reinecke <hare@xxxxxxx> wrote:
>
> While I do see the original appeal to have a rust-nvme driver, having
> one will just lead to confusion on all sides, especially for distros.
> (Why is it there? should it be preferred to the original one? Do we
> have to support both of them? Are there features missing in either
> of these drivers?)
> In general we are trying hard to avoid duplication in the linux kernel,
> especially on the driver side. We constantly have to fight^Wargue
> with driver vendors why duplicating existing drivers to support new
> hardware is a bad idea, so we really should not start now just because
> the driver is written in another language.
> (That really might be giving vendors bad ideas :-)

I think when Andreas refers to "reference driver" he may be referring
to the https://rust-for-linux.com/rust-reference-drivers framework. If
so, those are meant to be exceptional, temporary and well-justified.

So vendors cannot use it as an excuse to try to duplicate stuff (they
may try, but it should be clear it is not the same case).

And, for users, we should make it so that it is pretty clear they are
not intended to be used. Perhaps they could be gated behind EXPERT or
BROKEN or staging or similar. Perhaps even a new Kconfig option to
mark the ones we have (proposed in the list and in-tree) and that
allows to easily grep and to tweak the conditions under they can be
enabled etc.

Now, with that said, like Keith mentions, it should nevertheless be
clear what the final user of the abstractions are, i.e. the goal is to
bootstrap other code which will not be dead.

I hope that helps...

Cheers,
Miguel