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@xxxxxxxxxx> 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@xxxxxxxxxx Luis
