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: <2024121630-steed-grating-6352@gregkh>
Date: Mon, 16 Dec 2024 16:03:07 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: Andreas Hindborg <a.hindborg@...nel.org>,
	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

On Mon, Dec 16, 2024 at 07:43:12AM -0700, Jens Axboe wrote:
> On 12/16/24 6:02 AM, Andreas Hindborg wrote:
> >>> 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.
> 
> I'd have to agree with that - yes, null_blk doesn't host any real
> applications, but it is the backbone of a lot of testing that blktests
> and others do. Hence it's very real in that sense, and the rust version
> of null_blk should provide and mimic how the C version works for ease of
> testing.
> 
> If this was a new driver where no prior art exists in terms of users and
> API, then I'd certainly agree with Greg. But that's not the case here.

Ok, so are you going to drop the C version and go with the rust version
if it shows up?  Surely you don't want duplicate drivers for the same
thing in the tree, right?

thanks,

greg k-h