Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1310360 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc() "Luis R. Rodriguez" <mcgrof@do-not-panic.com> - 2016-01-15 19:30 +0100
    Re: [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc() Ingo Molnar <mingo@kernel.org> - 2016-01-19 12:20 +0100

#1310360 — Re: [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()

On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andrew Morton <akpm@linux-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

[toc] | [next] | [standalone]

#1312126

* Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:

> On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andrew Morton <akpm@linux-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

So beyond the rename, can we also keep the old names as compatibility helpers, 
with a #define mapping them to the new names?

If so then please (re-)send the changes.

Thanks,

	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web