On Mon, Jul 15, 2019 at 5:04 PM Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > > On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote: > > > > Linus, do you have any advice on how best to handle sharing mm > > > patches? The hmm.git was mildly painful as it sits between quilt on > > > the -mm side and what seems like 'a world of interesting git things' > > > on the DRM side (but maybe I just don't know enough about DRM). > > > > I think the approach in this merge window worked fairly well: > > - refactor/rework core mm stuff in (h)mm.git > > - handle all the gpu stuff in drm.git > > - make the clashes workable through some clever prep patches like > > we've done this time around > > Okay, as long as we agree. > > I think part of the challenge with hmm.git was setting some > expectation for managing conflicts - there is some happy middle ground > between none & scary we need to navigate to make this work. > > > I think Linus wants to be able to look through core mm stuff quite > > closely, so not a good idea if we deeply intertwin it with one of the > > biggest subsystems there is. > > There is definately a bunch of stuff that is under the mm/ directory > but is not quite 'core mm' - it would be good if we could rely on > mailing list review of that part and use a topic workflow to manage > things. This was/is more or less my plan with hmm.git > > Otherwise yes, as much as reasonable we should avoid topic merges > between the trees. > > However, I again see conflict risk coming this cycle .. > > > And I don't think there will be a real conflict like this every > > merge window, this should be the exception. Worst case we have to > > stage some work 1 release cycle apart, i.e. merge mm stuff first, > > then drm 3 months later. > > I really dislike this idea. Not being able to provide users for core > APIs is a huge process/review problem. Worse it tends to create a > 'ladder' where in-flight changes to drivers (to implement the new > core) now block any changes to the core APIs on alternating cycles. So > 'the big pitcture' starts to fall a part if we can't co-ordinate cross > tree changes in some way. > > .. and honestly, splitting a review process across a 9 week gap is one > of the best ways I've seen to get a poor quality review :( > > I'm pretty familiar with this problem, we had it in spades between RDMA > and netdev for a long time, and it is finally fully resolved now > through a careful use of topic branches and merges. > > For example, next week I'll queue CH's patches that shift the last > batch of hmm 'conflict management' shims into nouveau, and tries to > fix them: > > https://patchwork.kernel.org/project/linux-mm/list/?series=141835 > > This is something uncontroversial that really should go into the DRM > world as a topic so it doesn't interfere with ongoing nouveau dev. But > I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts. > > So, I'll put it on a topic and send you two a note next week to decide > if you want to merge it or not. I'm really unclear how nouveau's and > AMD's patchflow works.. DRM is 2-level for pretty much everything. First it lands in a driver tree (or a collectiv of drivers, like in drm-misc). Then those send pull requests to drm.git for integration. Busy trees do that every 1-2 weeks (e.g. amdgpu), slower trees once per merge window (e.g. nouveau) for drm-next, similar for drm-fixes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
