On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > Ok if this is just interim I think it's fine. Would still be good to have > the MAINTAINERS entry though even just to cover the interim state. Least > because I'm assuming that when things are split up you'd still want to > keep the rust list on cc for the rust parts, even when they move into > subsystems? Sorry, I missed to reply the second part of your email -- replying here. Currently, the subsystem's code is under `rust/` (though modules can go already into other folders). One of the reasons was technical simplicity, and a nice side effect is that we could bootstrap things while getting C maintainers involved over time. To accomplish that, the guidelines for contributing Rust code are that the respective maintainers need to be at least Cc'd, even if the files do not hit the `F:` fields for the time being -- see [1]. But, for us, ideally, the maintainers will take the changes through their tree, instead of going through the Rust one, since that is the end goal. And, of course, if you already want to have `F:` fields for the Rust code, that is even better! (Whether those should be in the same entry or in a new one, it is up to you, of course, and whether it is a different set of people / level of support / etc.) Then, when the `kernel` crate split happens, we can move the code directly under whatever folders it should be naturally, when their maintainers are ready. For some subsystems, that may mean they do not need any `F:` fields since they are already covered (e.g. if they did not create a new entry for Rust code only). And for cases like yours, where you already had `F:` fields, it means the move of the files can be done right away as soon as the split happens. In short, we would definitely welcome if you add `F:` fields already (whether in existing or new entries) -- it would mean you are ahead of the curve! :) As for the mailing list, yes, for the time being, I ask that all changes to please be sent to the Rust list, so that everybody that wants to follow the Rust progress has everything in a single place, so that we try to remain consistent in the beginning on e.g. coding guidelines, so that Rust reviewers can help spot mistakes, and so on and so forth. But, as Rust grows in the kernel, as systems become non-experimental, and as maintainers take ownership of the code, that should eventually go away and let things be as usual with C code. Then the Rust subsystem (and its list) will become smaller, and it will be the subsystem (and the discussion place) for anything not covered by other subsystems, such as core Rust abstractions and types, Rust infrastructure and so on. How does that sound? [1] https://rust-for-linux.com/contributing#the-rust-subsystem (I may reorganize this to be Rust's `P:` field, by the way) Cheers, Miguel
