On 5/12/24 12:39 PM, Andreas Hindborg wrote: > From: Andreas Hindborg <a.hindborg@xxxxxxxxxxx> > > Hi All! > > I am happy to finally send the first _non_ RFC patches for the Rust > block device API. > > This series provides an initial Rust block layer device driver API, > and a very minimal null block driver to exercise the API. The driver > has only one mode of operation and cannot be configured. > > These patches are an updated and trimmed down version of the v2 RFC > [1]. One of the requests for the v2 RFC was to split the abstractions > into smaller pieces that are easier to review. This is the first part > of the split patches. > > A notable change in this patch set is that they no longer use the > `ref` field of the C `struct request` to manage lifetime of the > request structure. > > The removed features will be sent later, as their dependencies land > upstream. > > As mentioned before, I will gladly maintain this code if required. With the following stipulations (and the kernel test bot issues sorted), I think we should give this a go. We already covered this today at LSFMM, but for the sake of others, here's how I see the rust support for the block side of things: I see rust support for the block layer as a two stage kind of thing. Stage 1 would be including this patchset. In stage 1, all fallout from block layer changes fall upon Andreas and group to fix. Under no circumstance will changes from other contributors be held up, or contributors be held accountable, for breakages of the block rust code. Should contributors wish to sort out these issues themselves, then they are of course free to do so, but it won't be something that gatekeeps other changes. This leaves existing contributors free to go about their usual business. Kernels that don't enable rust (which won't happen unless you're setup for it anyway) won't even see build breakages. We will see some noise from the kernel test bot on the list, which does worry me a little bit. Not because it'll mark the rust side as being broken, but because it'll cause more noise which may make us miss breakages that are ultimately more important. I don't think this is a big risk, just highlighting that it is indeed a risk and will cause some potential annoyances. In stage 1, block rust is just there to enable people to experiment and play with it, and continue to develop it. Right now Andreas has a very (VERY) basic null_blk driver, I think we should move towards a fully fledged implementation of that so we at least have _something_ to test. We really need to full API to be used and exposed, this is generic kernel requirement - we just don't merge code that has no users, ever. Since a more complete rust null blk driver does exist out of tree, perhaps we can get something more complete for v2 of this patchset? I would highly recommend that. We may never exit stage 1, and I think during this particular stage, if things don't work out for whatever reason, the code can be removed again. As we have no critical drivers being rust exclusive at that point, it won't cause any issues yanking the code again. Moving into a stage 2 for block rust would mean that the rest of the kernel has fully adopted rust anyway, and being able (and willing) to write rust is just another part of the developer arsenal. I'd love to see the rust code moved to eg block/rust/, as I would greatly prefer to have it closer to the actual block code rather than sitting off in rust/kernel/block instead. I see this as a similar problem to having documentation away fro the actual code, it inevitably causes a drift between them. I understand from Andreas that this is actually something that is being worked on, and we can probably expect to see that in a cycle or two. tldr - as long as this doesn't encumer existing contributors, then I see absolutely no reason not to enable a rust playground for block drivers. -- Jens Axboe
