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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ttb7d24p.fsf@kernel.org>
Date: Fri, 13 Dec 2024 16:38:30 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: "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

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

> On Fri, Dec 13, 2024 at 01:24:42PM +0100, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@...uxfoundation.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