On Wed, Apr 05, 2023 at 02:32:12PM +0200, Miguel Ojeda wrote: > 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? Yeah sounds all great! I think interim at least a separate rust drm entry would be good, to make sure we always cc both rust and dri-devel. Once it's too much for you and you generally trust the dri-devel folks to not design stupid interfaces, we can then drop that and only ping rust folks when needed. I do expect that's some years out though. -Daniel > > [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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
