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: <877c7zbx2u.fsf@kernel.org>
Date: Mon, 16 Dec 2024 14:02:01 +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>,  =?utf-8?Q?Bj=C3=B6rn?=
 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>,  "Jens Axboe" <axboe@...nel.dk>
Subject: Re: [PATCH v3 0/4] rust: extend `module!` macro with integer
 parameter support

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

> On Mon, Dec 16, 2024 at 10:51:53AM +0100, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@...uxfoundation.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