[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB=NE6UucJOwy3O58Oydoy_yR_05k0ebbBXpFVcNWM_g6ez-aA@mail.gmail.com>
Date: Fri, 15 Jan 2016 10:24:52 -0800
From: "Luis R. Rodriguez" <mcgrof@...not-panic.com>
To: Ingo Molnar <mingo@...nel.org>, Julia Lawall <julia.lawall@...6.fr>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
David Howells <dhowells@...hat.com>,
Borislav Petkov <bp@...e.de>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Dave Airlie <airlied@...ux.ie>,
linux-fbdev <linux-fbdev@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>, vinod.koul@...el.com,
Dan Williams <dan.j.williams@...el.com>,
Toshi Kani <toshi.kani@...com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"Michael S. Tsirkin" <mst@...hat.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()
On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
>
>> > 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.
>>
>> Yes it's a special case. I think the best way of handling such things is to get
>> them in to Linus either right at the end of the merge window or the day after he
>> releases -rc1. This is when most people's trees are mostly empty.
>
> Yes, that was the plan last time around as well - but the end of the merge window
> is when we have the least maintainer bandwidth as well ...
>
> Anyway, I applied most of the patches (sans the rename), so the rename patch
> should be a lot simpler to execute at the right moment this time around.
Ingo, should we try this again some time? I have some ideas on how to
make these sorts of changes easier to manage in the future, it
involves having an automatic git rebase option to use Coccinelle for
you if a patch is annotated to have been completely done with
Coccinelle, but future tooling is needed for that [0]. In the meantime
I (or you) can simply run the script at any point in time to catch all
the names as-is in the kernel / point in time we decide to merge this
simple rename.
[0] http://kernelnewbies.org/KernelProjects/linux-oven
Luis
Powered by blists - more mailing lists