On 12/16/24 8:03 AM, Greg KH wrote: > 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? Maybe at some point? The rust version is already there, it's just very limited compared to the C version so far. The point of the rust null_blk is to build out the API so that a real driver can get implemented as well. For now, I think the plan is to just have it be the rust playground on the block side. Given that null_blk is the center piece of a lot of testing, it's not necessarily an issue to have duplicate implementations of the same driver. In fact it may be pretty useful for people coming from either side and wanting to compare implementations and how to do various things in either language. It's like an actually useful skeleton driver in that sense too. Whether one or the other will be the only one in the tree in the future depends on a lot of other things that aren't necessarily driven or decided by the rust null_blk driver. -- Jens Axboe
