* Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [250214 07:20]: > On Fri, Feb 14, 2025 at 12:56:29PM +0100, Alice Ryhl wrote: > > On Thu, Feb 13, 2025 at 8:46 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > > > * Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [250213 07:16]: > > > > On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote: > > > > > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes > > > > > <lorenzo.stoakes@xxxxxxxxxx> wrote: > > > > > > > > > > > > Right, I don't mean the rust subsystem, I mean designated rust > > > > > > maintainers. The point being that this won't add workload to Andrew, nor > > > > > > require him nor other mm C people to understand rust. > > > > > > > > > > Sounds good, and apologies for being pedantic, but given the recent > > > > > discussions, I thought I should clarify just in case others read it > > > > > differently. > > > > > > > > > > In the same vein, one more quick thing (that you probably didn't mean > > > > > in this way, but still, I think it is better I add the note, sorry): I > > > > > don't think it is true that it will not add workload to Andrew or MM > > > > > in general. It always adds some workload, even if the maintainers > > > > > don't handle the patches at all, since they may still need to perform > > > > > a small change in something Rust related due to another change they > > > > > need to do, or perhaps at least contact the Rust sub-maintainer to do > > > > > it for them, etc. > > > > > > > > > > https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers > > > > > > > > > > Cheers, > > > > > Miguel > > > > > > > > Ack, for the record I'm happy to help with any work that might come up. > > > > > > Ack, here too. > > > > > > Without the drama, I'm not sure how we'd feel so alive :P > > > > > > Can I be added to whatever list so I can be Cc'ed on the changes on your > > > side? > > > > I'm happy to format the entries whichever way you all prefer, but for > > example it could be a new MAINTAINERS entry below MEMORY MAPPING along > > these lines: > > > > MEMORY MANAGEMENT/MAPPING [RUST] > > I think a general: > > MEMORY MANAGEMENT [RUST] > > works better here as it ought to (at least for the time being) cover off all > rust mm stuff. > > > M: Alice Ryhl <aliceryhl@xxxxxxxxxx> > > I wonder if we should have Andrew as a co-maintainer here so people also > send to Andrew also for merge? (and obviously as the mm maintainer he may > have commentary). Indeed, FWIU each subsystem is doing something different with some taking no responsibility/effort while others are involved. The mm space has been a very good citizen in both methods (merging with cover letters, code quality, etc) and in code (always on top of syzbot, bugs). I think it is important to strive to keep this functioning. This will become more important once we have more than just wrappers, but I think we should talk about what this will need to look like before it actually happens. ie: unstable rust branch tracking unstable c branch with build emails, etc? Early days yet, though. > > > R: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > Am happy to be a reviewer this is fine! > > > R: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > > I am sure Liam is also, but of course he can comment himself :) Yes, please add me here. > > > L: linux-mm@xxxxxxxxx > > L: rust-for-linux@xxxxxxxxxxxxxxx > > S: Maintained > > Probably need these here too if Andrew is taking in his tree: > > W: http://www.linux-mm.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm This is a good question. I am unclear how the branching/merging happens. When do we need to start (at lest) building the rust side? We've been doing a lot of work in the modularization/interface level to try and integrate more isolated testing, as well as the locking changes. Do you have build bots that will tell us when things are broken? ... Thanks, Liam
