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

[Andreas Hindborg]

Andreas Hindborg <a.hindborg@xxxxxxxxxx> writes:

> I would like to propose a session to discuss the status of Rust in the block
> subsystem. I have two distinct points to discuss: 1) The status of Rust in the
> block layer, and 2) the out-of-tree Rust NVMe driver.
>
> == The status of Rust in the block subsystem ==
>
> Rust has special status in the block subsystem [1]. We are currently at "Stage
> 1" of a two stage "kind of thing", where enabling Rust code in the block
> subsystem is essentially an experiment that can be terminated if it does not
> work out. In order to move on from this stage to "Stage 2", where Rust in the
> block subsystem is a first class citizen, we need two things. 1) We must observe
> that Rust is applicable for writing block device drivers and 2) the kernel in
> general must have fully adopted Rust.
>
> For 1) I just sent a patch series that brings the Rust null block driver to
> feature parity with the C counterpart [2]. Although the null block driver is not
> real hardware, I think this submission goes a long way to demonstrate that
> Rust is in fact applicable for writing block device drivers.
>
> For 2) I would point to the fact that Rust in general is no longer experimental
> in the kernel as a whole [3]. The "Rust Experiment" has been concluded,
> successfully. We see adoption in the form of the binder driver, and in the
> large, ongoing, effort targeting GPU drivers in the DRM subsystem. A few network
> PHY drivers also made it in. There is a lot of activity on the Rust list though,
> and I expect we will see Rust in more and more subsystems over the next few years.
>
> On that basis, I suggest we discuss whether or not we can move to "Stage 2" -
> and what that entails.
>
> == The out-of-tree Rust PCI NVMe driver ==
>
> As you may know, I am maintaining a Rust PCI NVMe driver out of tree. For the
> development work of the block layer Rust APIs, it has been essential to
> implement a real driver, in addition to the null block driver. A driver
> targeting actual hardware has to deal with interrupts, registers, IO memory,
> DMA, memory mappings, in a way that an emulated device does not. Keeping this
> driver around has helped shape the Rust block APIs in a way that makes sense for
> real devices, not just emulated ones.
>
> Rebasing this driver every cycle is a lot of work. Driven by requirements of the
> DRM drivers, core Rust APIs for DMA, register access, IO memory, etc. are being
> reshaped and rethought, which is great. Rebasing on top of these changes as a
> second class citizen all the time - not so great. But I believe that the Rust
> NVMe driver is a great piece of reference code, so I keep doing it.
>
> I would ask that we discuss merging the Rust NVMe driver so as to have a reference
> implementation of a real driver in-tree. I think it would have the following
> benefits:
>
>  - It would help ensure that the Rust block layer API actually works with real
>    devices.
>
>  - It would help make sure that the changes to core APIs that are made to
>    facilitate other subsystems are done in a way that is compatible with block
>    layer requirements.
>
>  - It would serve as a nice reference implementation and a great piece of
>    documentation.
>
>  - I would not have to rebase it all the time. Patches changing Rust APIs used
>    by Rust NVMe would have to change the Rust NVMe call sites.
>
> Please note the emphasis on *reference* driver. I am not suggesting to replace
> the existing C driver. I will maintain the new code if necessary.
>
> If we could establish consensus on this, I would clean up the driver to a state
> where it can be included in the kernel.
>
> Best regards,
> Andreas Hindborg
>
> Link: https://lore.kernel.org/r/593a98c9-baaa-496b-a9a7-c886463722e1@xxxxxxxxx [1]
> Link: https://lore.kernel.org/r/20260216-rnull-v6-19-rc5-send-v1-0-de9a7af4b469@xxxxxxxxxx [2]
> Link: https://lore.kernel.org/all/20251213000042.23072-1-ojeda@xxxxxxxxxx/ [3]

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.

Cc: Jens Axboe <axboe@xxxxxxxxx>,
Cc: Keith Busch <kbusch@xxxxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxx>
Cc: Sagi Grimberg <sagi@xxxxxxxxxxx>

Best regards,
Andreas Hindborg