On Mon, Dec 16, 2024 at 07:43:12AM -0700, Jens Axboe wrote: > On 12/16/24 6:02 AM, Andreas Hindborg wrote: > >>> I understand that you would like to phase out module parameters, but I > >>> don't think blocking their use from Rust is the right way to go about > >>> that task. If you really feel that module parameters have no place in > >>> new drivers, I would suggest that to be part of review process for each > >>> individual new driver - not at the stage of enabling module parameters > >>> for Rust in general. > >> > >> I'm saying that module parameters do NOT belong in a driver, which is > >> what you are wanting to do here. And as for adding new apis, please > >> only do so when you have a real user, I don't see a real user for module > >> parameters in rust just yet. If that changes, I'll reconsider my stance :) > > > > I guess we disagree about what is "real" and what is not. > > > > In my view, null_blk is real, it is used by real people to do real work. > > They get real annoyed when the interface for their real tools change - > > thus making it more difficult to do this experiment. > > I'd have to agree with that - yes, null_blk doesn't host any real > applications, but it is the backbone of a lot of testing that blktests > and others do. Hence it's very real in that sense, and the rust version > of null_blk should provide and mimic how the C version works for ease of > testing. > > If this was a new driver where no prior art exists in terms of users and > API, then I'd certainly agree with Greg. But that's not the case here. Ok, so are you going to drop the C version and go with the rust version if it shows up? Surely you don't want duplicate drivers for the same thing in the tree, right? thanks, greg k-h
