Message-ID: <64a40555-e3f8-4671-8ece-3c3b677ccdfb@kernel.dk>
Date: Mon, 16 Dec 2024 08:08:32 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Andreas Hindborg <a.hindborg@...nel.org>, Miguel Ojeda
 <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>,
 Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
 <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
 Trevor Gross <tmgross@...ch.edu>, Adam Bratschi-Kaye <ark.email@...il.com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v3 0/4] rust: extend `module!` macro with integer
 parameter support

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

Powered by blists - more mailing lists