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: <ZplNxxXS3RLULeI6@bombadil.infradead.org>
Date: Thu, 18 Jul 2024 10:15:51 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Kris Van Hees <kris.van.hees@...cle.com>,
	Sami Tolvanen <samitolvanen@...gle.com>
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>
Subject: Re: [PATCH] rust: add `module_params` macro

On Tue, Jul 09, 2024 at 12:08:16PM +0200, Miguel Ojeda wrote:
> 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.
> 
> 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.

Great well then my preference is to not have Rust bindings for modules
unless the Rust community can commit to not only a co-maintianer for
both C And Rust but also commit to not ditching the role; if a C/Rust
co-maintainer gets hits by a bus the Rust community would strive to
look for someone else to step in. This would proactively help with
upstream responsibilities understood by companies who hire developers
in this context. It is why I brought up Andreas's work, I already know
he has a lot of work to do and responsibilities. If not Andreas, who else
can step up to help with this, Sami? While each company varies in
accepting a developer's roles in the community, I think we would stand
to gain to consider the long term aspects of this before it becomes an
issue, so we get employers to understand / accept this as part of our
work. I don't think this is an unreasonable for companies or developers
interested in Rust advancements.

This includes testing, helping improve tests and using existing tests
or automation tools for them so we don't regress.

Clearly, this isn't just about a module_params macro, for example
I'm starting to see other module related code I need to review and
having to be very careful to ensure all of what is ongoing with modules
like Kris's work on kbuild CONFIG_BUILTIN_MODULE_RANGES will still work
in a Rust modules world with Sami's work on module modversions.

[0] https://lkml.kernel.org/r/20240716031045.1781332-1-kris.van.hees@oracle.com

  Luis