linux-kernel - Re: [PATCH] rust: add `module

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: <ZoxdRjpy2hRndqmc@bombadil.infradead.org>
Date: Mon, 8 Jul 2024 14:42:30 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Andreas Hindborg <nmi@...aspace.dk>
Cc: Miguel Ojeda <ojeda@...nel.org>, rust-for-linux@...r.kernel.org,
	linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Adam Bratschi-Kaye <ark.email@...il.com>,
	Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: [PATCH] rust: add `module_params` macro

On Fri, Jul 05, 2024 at 11:15:11AM +0000, Andreas Hindborg wrote:
> From: Andreas Hindborg <a.hindborg@...sung.com>
> 
> This patch includes changes required for Rust kernel modules to utilize
> module parameters. This code implements read only support for integer
> types without `sysfs` support.
> 
> This code is a reduced and updated version of code by Adam available in the
> original `rust` branch [1].
> 
> [1] https://github.com/Rust-for-Linux/linux/tree/bc22545f38d74473cfef3e9fd65432733435b79f
> 
> Cc: Adam Bratschi-Kaye <ark.email@...il.com>
> Signed-off-by: Andreas Hindborg <a.hindborg@...sung.com>
> 

This poses an interesting challenge I'd like to take up with the Rust
community. I'm fine with Rust bindings, however many C maintainers
neither don't speak / write Rust, and in many cases many don't even want
to touch Rust at all. In my case I want to get there.. but just haven't
had time yet. So we have to live with that world. But to help with a
Rust world, clearly we need to allow for some Rust bindings.

As a compromise, I recently suggested for example for the firmware_loader
Rust bindings to be acceptable if and only if we could get the developer
doing those changes to be willing to commit to also being *both* a C and
rust maintainer for the firmware loader.

I'm starting to feel the same way about modules, but modules requires
more work than the firmware loader. And since I also know Andreas has
already a lot on his plate, I'm at a cross roads.  My above request for
the firmware loader made sense to the person working on the firmware
loader changes, but who would help on the modules side of things? And
does this request make sense to help scale?

The rationale here is that a rust binding means commitment then also
from fresh blood to help co-maintain review C / Rust for exising code
when there is will / desire to collaborate from an existing C maintainer.

I realize this may be a lot to ask, but I think this is one of the
responsible ways to ask to scale here.

  Luis