On Tue, Feb 25, 2025 at 11:22 AM Petr Pavlu <petr.pavlu@xxxxxxxx> wrote:
>
> 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.
>
> 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?
Up to you, of course -- a couple days ago (in the context of the
hrtimer thread) I wrote a summary of the usual discussion we have
around this (copy-pasting here for convenience):
So far, what we have been doing is ask maintainers, first, if they
would be willing take the patches themselves -- they are the experts
of the subsystem, know what changes are incoming, etc. Some subsystems
have done this (e.g. KUnit). That is ideal, because the goal is to
scale and allows maintainers to be in full control.
Of course, sometimes maintainers are not fully comfortable doing that,
since they may not have the bandwidth, or the setup, or the Rust
knowledge. In those cases, we typically ask if they would be willing
to have a co-maintainer (i.e. in their entry, e.g. like locking did),
or a sub-maintainer (i.e. in a new entry, e.g. like block did), that
would take care of the bulk of the work from them.
I think that is a nice middle-ground -- the advantage of doing it like
that is that you get the benefits of knowing best what is going on
without too much work (hopefully), and it may allow you to get more
and more involved over time and confident on what is going on with the
Rust callers, typical issues that appear, etc. Plus the sub-maintainer
gets to learn more about the subsystem, its timelines, procedures,
etc., which you may welcome (if you are looking for new people to get
involved).
I think that would be a nice middle-ground. As far as I understand,
Andreas would be happy to commit to maintain the Rust side as a
sub-maintainer (for instance). He would also need to make sure the
tree builds properly with Rust enabled and so on. He already does
something similar for Jens. Would that work for you?
You could take the patches directly with his RoBs or Acked-bys, for
instance. Or perhaps it makes more sense to take PRs from him (on the
Rust code only, of course), to save you more work. Andreas does not
send PRs to anyone yet, but I think it would be a good time for him to
start learning how to apply patches himself etc.
If not, then the last fallback would be putting it in the Rust tree as
a sub-entry or similar.
I hope that clarifies (and thanks whatever you decide!).
https://lore.kernel.org/rust-for-linux/CANiq72mpYoig2Ro76K0E-sUtP31fW+0403zYWd6MumCgFKfTDQ@xxxxxxxxxxxxxx/
Would any of those other options work for you?
Thanks!
Cheers,
Miguel
