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

[Hannes Reinecke <hare@suse.de>]

On 3/17/26 00:51, Keith Busch wrote:
> On Wed, Mar 11, 2026 at 02:21:00PM +0100, Andreas Hindborg wrote:
>> As this topic was not selected for discussion at LSF, and I did not
>> receive an invitation for LSF this year, I propose that we discuss these
>> two topics on list.
>>
>> I do believe that these topics need to be discussed, and I would very
>> much appreciate your input.
> 
> I can sympathise the difficulty of maintaining external modules.
> 
> In terms of this being a reference driver, that implies some future
> hardware driver may leverage this for its development. Is there anything
> in mind at this point for production? If so, maybe that use case should
> take the lead. But either way, I think rust-nvme upstream inclusion
> would invite confusion. Once it's upstream, it's no longer a reference
> when distros and users turn it on.
> 
I wholeheartedly agree.

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 :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich