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

Andreas Hindborg
2024-12-16T13:04:38Z

"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