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: <CANiq72=VU+PHfkiq8HokfeCEKvQoeBiUaB76XbW6s3f2zYmEtA@mail.gmail.com>
Date: Tue, 9 Jul 2024 12:08:16 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Andreas Hindborg <nmi@...aspace.dk>, 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 Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> 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.

Yeah, there have been different approaches for this taken by different
subsystems -- it depends on their constraints and how much the
submitter can commit to.

For instance, some maintainers may want to keep being the maintainers
of both Rust and C. Some want that the submitter becomes a new
co-maintainer in the subsystem and eventually maintainers both C and
Rust. Some prefer to have a new maintainer for the Rust side only,
i.e. considering Rust as a new section of the subsystem with a new
`MAINTAINERS` entry and all.

On top of that, some allow the C and Rust sides to be independent, to
the point of allowing temporary breakage on the Rust side if the new
maintainers commits to be quick fixing it (though I have my
reservations about how well that would eventually work if more
core/common subsystems start doing that -- linux-next could be broken
a lot of the time for the Rust side).

But, yes, I think Rust is a great opportunity to get new
co-maintainers, as well as getting new developers involved with kernel
maintenance in general, which could help with other issues too.

Cheers,
Miguel