[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d9e596a-5316-4e00-862b-fd77552ae4b5@suse.com>
Date: Tue, 25 Feb 2025 11:22:07 +0100
From: Petr Pavlu <petr.pavlu@...e.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: 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>, Trevor Gross <tmgross@...ch.edu>,
Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
<nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
Luis Chamberlain <mcgrof@...nel.org>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, Adam Bratschi-Kaye <ark.email@...il.com>,
linux-kbuild@...r.kernel.org, Daniel Gomez <da.gomez@...sung.com>,
Simona Vetter <simona.vetter@...ll.ch>, Greg KH
<gregkh@...uxfoundation.org>, linux-modules@...r.kernel.org,
Miguel Ojeda <ojeda@...nel.org>, Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: [PATCH v7 0/6] rust: extend `module!` macro with integer
parameter support
On 2/24/25 12:27, Andreas Hindborg wrote:
> Hi Petr,
>
> "Andreas Hindborg" <a.hindborg@...nel.org> writes:
>
>> This series extends the `module!` macro with support module parameters. It
>> also adds some string to integer parsing functions and updates `BStr` with
>> a method to strip a string prefix.
>>
>> This series stated out as code by Adam Bratschi-Kaye lifted from the original
>> `rust` branch [1].
>>
>> After a bit of discussion on v3 about whether or not module parameters
>> is a good idea, it seems that module parameters in Rust has a place
>> in the kernel for now. This series is a dependency for `rnull`, the Rust
>> null block driver [2].
>
>
> Luis told me you are the one wearing the modules hat for the moment. How
> do you want to handle merging of patch 6 and subsequent maintenance of
> the code?
I'd say the easiest is for the entire series to go through the Rust
tree. I'd also propose that any updates go primarily through that tree
as well.
>
> I think we discussed you guys taking this under the current module
> maintainer entry? If that is correct, will you add the new files to your
> entry yourself, or should I include an update to MAINTAINERS in the next
> version of this series?
Makes sense, I think it is useful for all changes to this code to be
looked at by both Rust and modules people. To that effect, we could add
the following under the MODULES SUPPORT entry:
F: rust/kernel/module_param.rs
F: rust/macros/module.rs
My slight worry is that this might suggest the entirety of maintenance
is on the modules folks. Fortunately, adding the above and running
get_maintainer.pl on rust/kernel/module_param.rs gives me a list of
people for both Rust and modules, so this could be ok?
--
Thanks,
Petr
Powered by blists - more mailing lists