On 2/25/25 12:54, Miguel Ojeda wrote: > 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?
