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 Fri, Dec 13, 2024 at 01:24:42PM +0100, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@linuxfoundation.org> writes:
>>
>> > On Fri, Dec 13, 2024 at 12:30:45PM +0100, Andreas Hindborg wrote:
>> >> This series extends the `module!` macro with support module parameters.
>> >
>> > Eeek, why?
>> >
>> > Module parameters are from the 1990's, back when we had no idea what we
>> > were doing and thought that a simple "one variable for a driver that
>> > controls multiple devices" was somehow a valid solution :)
>> >
>> > Please only really add module parameters if you can prove that you
>> > actually need a module parameter.
>>
>> I really need module parameters to make rust null block feature
>> compatible with C null block.
>
> Is that a requirement?  That wasn't documented here :(
>
> You should have put the user of these apis in the series as you have
> that code already in the tree, right?

Sorry, my mistake. I'm trying to build a rust implementation of C
null_blk, and one the bits I need for that is module parameters.

>
>> Let's not block interfacing parts of the kernel because we decided that
>> the way we (well not me, I was not around) did things in the 80's was
>> less than stellar. I mean, we would get nowhere.
>
> On the contrary, if we don't learn from our past mistakes, we will
> constantly keep making them and prevent others from "doing the right
> thing" by default.
>
> I would strongly prefer that any driver not have any module parameters
> at all, as drivers don't work properly that way (again, they need to
> handle multiple devices, which does not work for a module parameter.)
>
> That's why we created sysfs, configfs, and lots of other things, to
> learn from our past mistakes.

OK. I understand. It makes sense even :) I wish I knew that this was a
thing before I spent spare cycles fixing this up for v3 though.

I'm not getting a clear reading on the following, perhaps you can
clarify:

 - Is the community aligned on dropping module parameters for all new
   drivers?
   - If so, was this decided upon at some point or is this a fluid
     decision that is just manifesting now?
 - Does this ban of module parameters also cover cases where backwards
   compatibility is desirable?
 - 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?

Best regards,
Andreas Hindborg