On Fri, Jul 05, 2024 at 11:15:11AM +0000, Andreas Hindborg wrote: > From: Andreas Hindborg <a.hindborg@xxxxxxxxxxx> > > This patch includes changes required for Rust kernel modules to utilize > module parameters. This code implements read only support for integer > types without `sysfs` support. > > This code is a reduced and updated version of code by Adam available in the > original `rust` branch [1]. > > [1] https://github.com/Rust-for-Linux/linux/tree/bc22545f38d74473cfef3e9fd65432733435b79f > > Cc: Adam Bratschi-Kaye <ark.email@xxxxxxxxx> > Signed-off-by: Andreas Hindborg <a.hindborg@xxxxxxxxxxx> > This poses an interesting challenge I'd like to take up with the Rust community. I'm fine with Rust bindings, however many C maintainers neither don't speak / write Rust, and in many cases many don't even want to touch Rust at all. In my case I want to get there.. but just haven't had time yet. So we have to live with that world. But to help with a Rust world, clearly we need to allow for some Rust bindings. As a compromise, I recently suggested for example for the firmware_loader Rust bindings to be acceptable if and only if we could get the developer doing those changes to be willing to commit to also being *both* a C and rust maintainer for the firmware loader. I'm starting to feel the same way about modules, but modules requires more work than the firmware loader. And since I also know Andreas has already a lot on his plate, I'm at a cross roads. My above request for the firmware loader made sense to the person working on the firmware loader changes, but who would help on the modules side of things? And does this request make sense to help scale? 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. Luis
