rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Kris Van Hees <kris.van.hees@oracle.com>,
	Sami Tolvanen <samitolvanen@google.com>
Cc: Andreas Hindborg <nmi@metaspace.dk>,
	Miguel Ojeda <ojeda@kernel.org>,
	rust-for-linux@vger.kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Andreas Hindborg <a.hindborg@samsung.com>,
	Adam Bratschi-Kaye <ark.email@gmail.com>
Subject: Re: [PATCH] rust: add `module_params` macro
Date: Thu, 18 Jul 2024 10:15:51 -0700	[thread overview]
Message-ID: <ZplNxxXS3RLULeI6@bombadil.infradead.org> (raw)
In-Reply-To: <CANiq72=VU+PHfkiq8HokfeCEKvQoeBiUaB76XbW6s3f2zYmEtA@mail.gmail.com>

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@kernel.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

  reply	other threads:[~2024-07-18 17:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-05 11:15 [PATCH] rust: add `module_params` macro Andreas Hindborg
2024-07-05 11:33 ` Andreas Hindborg
2024-07-08 21:42 ` Luis Chamberlain
2024-07-09  6:00   ` nmi
2024-07-09  8:27     ` Greg KH
2024-07-09  9:25       ` nmi
2024-07-09 10:08   ` Miguel Ojeda
2024-07-18 17:15     ` Luis Chamberlain [this message]
2024-07-24 17:04       ` Sami Tolvanen
     [not found]         ` <CGME20240819200056eucas1p1589eddef05f72d97836f1d5be889048b@eucas1p1.samsung.com>
2024-08-19 20:00           ` Daniel Gomez
2024-08-19 21:59         ` Luis Chamberlain
2024-07-29 17:16 ` Benno Lossin
2024-08-01 11:29   ` Andreas Hindborg
2024-08-01 12:25     ` Benno Lossin
2024-08-01 13:40       ` Andreas Hindborg
2024-08-01 14:21         ` Benno Lossin
2024-08-01 15:11           ` Andreas Hindborg
2024-08-01 19:28             ` Benno Lossin
2024-08-02 10:27               ` Andreas Hindborg
2024-08-02 17:11                 ` Benno Lossin
2024-08-05 10:55                   ` Andreas Hindborg
2024-08-06  8:09                     ` Benno Lossin
2024-08-15 13:11                       ` Andreas Hindborg
2024-08-15 19:33                         ` Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZplNxxXS3RLULeI6@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=a.hindborg@samsung.com \
    --cc=ark.email@gmail.com \
    --cc=kris.van.hees@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=nmi@metaspace.dk \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).