On 11/7/26 21:09, Lorenzo Stoakes (ARM) wrote: > I think we're slightly talking across purposes, so to be clear - I am totally > fine with you taking any of this through your tree or whatever works for you > and > Andrew to avoid merge pain :) > > I was just talking more generally about how to merge series that touch a lot > of > subsystems and maintainers-who-may-never-reply, etc. > > These are the edge cases that make things... fun :) > > Anyway, I guess easiest resolution here is for you to take the bits that > belong > to your trees and Andrew takes the bits that belong elsewhere?
Yes, that's what I did now, applying #1,#3,#4,#5,#6 7+8 touches some of my components, but the chance for conflicts are hopefully small. > > I don't think anything here has an inter-dependency. > Yeah that makes it a lot easier. > > On Sat, Nov 07, 2026 at 08:26:29PM +0100, David Hildenbrand (Arm) wrote: > [ ... ] >> >> Because of [PATCH 05/13] mm: convert THP VMA flag tests to use vma_flags_t >> which >> is THP-only, and feels like it could go straight through one of my trees, >> avoiding conflicts with Andrew's tree. But maybe there is more to it that I >> am >> missing. > > Sorry about that! Please take that through your tree. > Not your fault, I guess we'll have to get used to merging stuff through separate trees, and dealing with conflicts that cannot be avoided :) >> >> I assume stable topic branches would fix that, but they are currently >> unfortunately not on the table ... :) > > I guess we need everybody-on-git for this! > > I guess when Liam and & I have the VMA tree we can do that at least for stuff > that goes there :) Ack! > >> >>> >>> >>> Right, but sometimes functions are declared in one place and called in >>> others. It is impossible to change the signature of one without also >>> touching >>> the others. >> >> Yes. Something like that is unavoidable. Or if you need new APIs/ > > Yes. > >> >>> >>> >>> It's not really all over the place, it's converting vm_flags_t to >>> vma_flags_t across madvise.c, which involves changing a few function >>> signatures, whose callers must be updated. >> >> Ah, yeah. What on earth does arch/powerpc/kvm/book3s_hv_uvmem.c do with >> madvise :( > > Yeah it's quite worrying that... :) > >> >>> >>> I could split it up into 3 patches where 1 does internal-only, one changes 1 >>> function, and the next changes another, if that works? >> >> No, these things really have to go in as one unit, no need to split that up. > > Thanks, yeah, it's a pain I know but eventually 'one fine day' (probably in > 2028) everything will be converted to vma_flags_t/mmap_prepare and we won't > have > to think about this :P Right! :) -- Cheers, David
