On 5/4/23 12:52?PM, Keith Busch wrote: > On Thu, May 04, 2023 at 11:36:01AM -0700, Bart Van Assche wrote: >> On 5/4/23 11:15, Andreas Hindborg wrote: >>> If it is still unclear to you why this effort was started, please do let >>> me know and I shall try to clarify further :) >> >> It seems like I was too polite in my previous email. What I meant is that >> rewriting code is useful if it provides a clear advantage to the users of >> a driver. For null_blk, the users are kernel developers. The code that has >> been posted is the start of a rewrite of the null_blk driver. The benefits >> of this rewrite (making low-level memory errors less likely) do not outweigh >> the risks that this effort will introduce functional or performance regressions. > > Instead of replacing, would co-existing be okay? Of course as long as > there's no requirement to maintain feature parity between the two. > Actually, just call it "rust_blk" and declare it has no relationship to > null_blk, despite their functional similarities: it's a developer > reference implementation for a rust block driver. To me, the big discussion point isn't really whether we're doing null_blk or not, it's more if we want to go down this path of maintaining rust bindings for the block code in general. If the answer to that is yes, then doing null_blk seems like a great choice as it's not a critical piece of infrastructure. It might even be a good idea to be able to run both, for performance purposes, as the bindings or core changes. But back to the real question... This is obviously extra burden on maintainers, and that needs to be sorted out first. Block drivers in general are not super security sensitive, as it's mostly privileged code and there's not a whole lot of user visibile API. And the stuff we do have is reasonably basic. So what's the long term win of having rust bindings? This is a legitimate question. I can see a lot of other more user exposed subsystems being of higher interest here. -- Jens Axboe
