Re: [Xen-devel] [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Tue, Aug 25, 2015 at 01:43:58PM -0700, Andrew Morton wrote:
> On Tue, 25 Aug 2015 17:48:37 +0200 "Luis R. Rodriguez" <mcgrof@xxxxxxxx> 
> wrote:
> 
> > On Tue, Aug 25, 2015 at 09:53:18AM +0200, Ingo Molnar wrote:
> > > Which kernel is this against? It has conflicts in 3 files with Linus's 
> > > latest: 
> > > v4.2-rc8.
> > 
> > Sorry I based it on linux-next, will respin the rename patch onto 
> > tip/auto-latest
> > 
> 
> Doing that will make the patch kinda useless, because then the patch
> will trash more mature work which is pending in linux-next, one week
> before the merge window opens.
> 
> A better plan would be to base the patches on linux-next then wait for
> 4.3-rc1.

There's a catch-22 issue here either way, for instance this rename
patch has been being baked for probably 2 releases already but the
difficulty has been trying to find the appropriate time to merge it
without conflict.

If you do it in the beginning of the merge window, you have to ask
yourself in what tree it will be done. Since subsystems are topic
specific that means that subsystem will end up having a conflict
at the end of the merge window.

If you do it at the end you run into the issue you describe.

So unless I'm missing something, perhaps metrics to argue one way is better
than another, it seems today this is up up to a subsystem's maintainer's
preference?

There are more subtle issues with this though, I've identified similar problems
before and proposed one solution to it could be a linux-oven [0], in that
thread I describe other issues and why I think a linux-oven might help.

Perhaps the biggest change that comes to mind that could have caused
tons of collateral was the UAPI change David Howells did years ago,
when did that go in, at the end of early? In retrospect what would have
helped?

Anyway, both version of the patch are now available, up to you guys :)

[0] http://lkml.kernel.org/r/20150619231255.GC7487@xxxxxxxxxxxxxxxxxxxxxxxxx

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel