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.
