Re: [PATCH v3 0/4] rust: extend `module!` macro with integer parameter support

[Andreas Hindborg <a.hindborg@kernel.org>]

"Greg KH" <gregkh@linuxfoundation.org> writes:

> On Mon, Dec 16, 2024 at 10:51:53AM +0100, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@linuxfoundation.org> writes:
>>
>> > On Fri, Dec 13, 2024 at 04:38:30PM +0100, Andreas Hindborg wrote:

[cut]

>> >
>> >>  - Can we merge this so I can move forward at my current projected
>> >>    course, or should I plan on dealing with not having this available?
>> >
>> > We generally do not want to merge apis without any real users, as it's
>> > hard to justify them, right?  Also, we don't even know if they work
>> > properly or not.
>>
>> While null_blk is just a piece of testing infrastructure that you would
>> not deploy in a production environment, it is still a "real user". I am
>> sure we can agree on the importance of testing.
>>
>> The exercise I am undertaking is to produce a drop in replacement of the
>> existing C null_blk driver. If all goes well, we are considering to swap
>> the C implementation for the Rust implementation in X number of years.
>> Granted - a lot of things have to fall into place for that to happen,
>> but that is the plan. This plan does not really work well if the two
>> modules do not have the same interface.
>
> Why do you have to have the same interface?  Why not do it "properly"
> and make it use configfs that way you can have multiple devices and test
> them all at the same time?
>
> As this is "just" a testing driver, there should not be any need to keep
> the same user/kernel api for setting things up, right?

Because that would break all the users that use the old interface.

>
> Again, don't make the mistakes we have in the past, drivers should NOT
> be using module parameters.
>
>> 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.


Best regards,
Andreas Hindborg