linux-next: please add queue for removal of __cpuinit and friends.

linux-next: please add queue for removal of __cpuinit and friends.

[Paul Gortmaker]

Hi Stephen,

Would you please add the patch queue below to linux-next for
the remainder of this week and the two weeks of the merge window?

It is the patch queue for removal of __cpuinit ; a git repository
of patches with a series file that can be browsed here:

  http://git.kernel.org/cgit/linux/kernel/git/paulg/cpuinit-delete.git

or cloned directly from here:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/cpuinit-delete.git

and the deletion and merge strategy was described here previously:

  https://lkml.org/lkml/2013/6/20/513

I have been tracking it manually myself by re-applying it locally
to the daily linux-next tree each day for a while now (you can see
patch refresh history in the repo for anyone wishing that level of
detail).

I do not expect any significant changes to the repository going forward.
Perhaps adding a couple more "Acked-by:" tags, and dropping a couple
patches for when maintainers request to carry them locally.  So I hope
it should not be a big burden.  And it is a one-shot tree as well.

Thanks,
Paul.
--

Re: linux-next: please add queue for removal of __cpuinit and friends.

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

Hi Paul,

On Tue, 25 Jun 2013 11:27:02 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> Would you please add the patch queue below to linux-next for
> the remainder of this week and the two weeks of the merge window?

Maybe.  I will see how much pain it causes me.

> It is the patch queue for removal of __cpuinit ; a git repository
> of patches with a series file that can be browsed here:
> 
>   http://git.kernel.org/cgit/linux/kernel/git/paulg/cpuinit-delete.git
> 
> or cloned directly from here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/cpuinit-delete.git
> 
> and the deletion and merge strategy was described here previously:
> 
>   https://lkml.org/lkml/2013/6/20/513

Yeah, I should have responded to that.  Given that the meat of this
series is the first 2 patches (the rest is merely cleaning up the uses of
the now mulled out macros, right) I think it would have been better (i.e.
easier for me :-)) if you had a git tree based on v3.10-rc<something> and
then did a sweep after v3.11-rc1 was out to clean up the rest.

> I do not expect any significant changes to the repository going forward.
> Perhaps adding a couple more "Acked-by:" tags, and dropping a couple
> patches for when maintainers request to carry them locally.  So I hope
> it should not be a big burden.  And it is a one-shot tree as well.

The problem is that it is based on shifting sands i.e. linux-next.  This
means that I will have to rebase it each day onto the new linux-next just
before I release it.  I already do this with Andrew's tree and that is a
bit of a pain already.

It also means (given that some linus-next included trees do not actually
get merged for -rc1), that some of these patches may never apply cleanly
to Linus' tree.

I will try it today and see how we go.  I assume that the current set of
patches is based on next-20130625?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: please add queue for removal of __cpuinit and friends.

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

Hi Paul,

On Wed, 26 Jun 2013 11:22:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I will try it today and see how we go.  I assume that the current set of
> patches is based on next-20130625?

OK, its in today.  Just for info (at the end of today's linux-next):

$ git grep -l __cpuinit
arch/arm/mach-keystone/platsmp.c
arch/arm/mach-sti/platsmp.c
arch/mips/ath79/setup.c
arch/mips/cavium-octeon/octeon-irq.c
arch/mips/cavium-octeon/smp.c
arch/mips/include/asm/uasm.h
arch/mips/kernel/cevt-bcm1480.c
arch/mips/kernel/cevt-gic.c
arch/mips/kernel/cevt-r4k.c
arch/mips/kernel/cevt-sb1250.c
arch/mips/kernel/cevt-smtc.c
arch/mips/kernel/cpu-bugs64.c
arch/mips/kernel/cpu-probe.c
arch/mips/kernel/smp-bmips.c
arch/mips/kernel/smp-mt.c
arch/mips/kernel/smp-up.c
arch/mips/kernel/smp.c
arch/mips/kernel/smtc.c
arch/mips/kernel/spram.c
arch/mips/kernel/sync-r4k.c
arch/mips/kernel/traps.c
arch/mips/kernel/watch.c
arch/mips/lantiq/irq.c
arch/mips/lib/uncached.c
arch/mips/mm/c-octeon.c
arch/mips/mm/c-r3k.c
arch/mips/mm/c-r4k.c
arch/mips/mm/c-tx39.c
arch/mips/mm/cache.c
arch/mips/mm/page.c
arch/mips/mm/sc-ip22.c
arch/mips/mm/sc-mips.c
arch/mips/mm/sc-r5k.c
arch/mips/mm/sc-rm7k.c
arch/mips/mm/tlb-r3k.c
arch/mips/mm/tlb-r4k.c
arch/mips/mm/tlb-r8k.c
arch/mips/mm/tlbex.c
arch/mips/mti-malta/malta-smtc.c
arch/mips/mti-malta/malta-time.c
arch/mips/mti-sead3/sead3-time.c
arch/mips/netlogic/common/smp.c
arch/mips/netlogic/common/time.c
arch/mips/netlogic/xlr/wakeup.c
arch/mips/pci/pci-ip27.c
arch/mips/pmcs-msp71xx/msp_smtc.c
arch/mips/pmcs-msp71xx/msp_time.c
arch/mips/pnx833x/common/interrupts.c
arch/mips/powertv/time.c
arch/mips/ralink/irq.c
arch/mips/sgi-ip27/ip27-init.c
arch/mips/sgi-ip27/ip27-smp.c
arch/mips/sgi-ip27/ip27-timer.c
arch/mips/sgi-ip27/ip27-xtalk.c
arch/mips/sibyte/bcm1480/smp.c
arch/mips/sibyte/sb1250/smp.c
arch/x86/include/asm/microcode_amd.h
arch/x86/include/asm/processor.h
arch/x86/kernel/i387.c
arch/x86/kernel/microcode_amd_early.c
include/linux/init.h
scripts/tags.sh
$ git grep -l __cpuexit
arch/blackfin/mach-common/smp.c
arch/metag/kernel/smp.c
include/linux/init.h
$ git grep -l __cpuinitdata
arch/mips/cavium-octeon/octeon-irq.c
arch/mips/include/asm/uasm.h
arch/mips/kernel/cpu-bugs64.c
arch/mips/kernel/cpu-probe.c
arch/mips/kernel/sync-r4k.c
arch/mips/kernel/traps.c
arch/mips/mm/c-r4k.c
arch/mips/mm/page.c
arch/mips/mm/tlb-r4k.c
arch/mips/mm/tlbex.c
include/linux/init.h
scripts/tags.sh
$ git grep -l __cpuinitconst
include/linux/init.h
$ git grep -l __cpuexitdata
include/linux/init.h
$ git grep -l __cpuexitconst
include/linux/init.h
$ git grep -l __CPUINIT
arch/arm/kernel/head-nommu.S
arch/mips/kernel/bmips_vec.S
arch/mips/kernel/head.S
arch/mips/mm/cex-sb1.S
arch/mips/netlogic/common/smpboot.S
include/linux/init.h

So I guess the Ralf hasn't put the mips patch in his mips-for-linux-next
branch yet.  And a few more uses have crept in. :-(

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: please add queue for removal of __cpuinit and friends.

[Paul Gortmaker]

[Re: linux-next: please add queue for removal of __cpuinit and friends.] On 26/06/2013 (Wed 17:38) Stephen Rothwell wrote:

> Hi Paul,
> 
> On Wed, 26 Jun 2013 11:22:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I will try it today and see how we go.  I assume that the current set of
> > patches is based on next-20130625?
> 
> OK, its in today.  Just for info (at the end of today's linux-next):
> 
> $ git grep -l __cpuinit
> arch/arm/mach-keystone/platsmp.c
> arch/arm/mach-sti/platsmp.c
> arch/mips/ath79/setup.c
> arch/mips/cavium-octeon/octeon-irq.c
> arch/mips/cavium-octeon/smp.c

[...]

> arch/mips/kernel/bmips_vec.S
> arch/mips/kernel/head.S
> arch/mips/mm/cex-sb1.S
> arch/mips/netlogic/common/smpboot.S
> include/linux/init.h
> 
> So I guess the Ralf hasn't put the mips patch in his mips-for-linux-next
> branch yet.  And a few more uses have crept in. :-(

Odd.  It was in mips-for-linux-next on the 20th.  Accidentally dropped?

I've re-inserted the mips patch into my patch queue, fixed up the new
uses that crept in, and refreshed the arm patch that gained a conflict.

Thanks,
Paul.
--

> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: please add queue for removal of __cpuinit and friends.

[Paul Gortmaker]

[Re: linux-next: please add queue for removal of __cpuinit and friends.] On 26/06/2013 (Wed 11:22) Stephen Rothwell wrote:

> Hi Paul,
> 
> On Tue, 25 Jun 2013 11:27:02 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > Would you please add the patch queue below to linux-next for
> > the remainder of this week and the two weeks of the merge window?
> 
> Maybe.  I will see how much pain it causes me.
> 
> > It is the patch queue for removal of __cpuinit ; a git repository
> > of patches with a series file that can be browsed here:
> > 
> >   http://git.kernel.org/cgit/linux/kernel/git/paulg/cpuinit-delete.git
> > 
> > or cloned directly from here:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/cpuinit-delete.git
> > 
> > and the deletion and merge strategy was described here previously:
> > 
> >   https://lkml.org/lkml/2013/6/20/513
> 
> Yeah, I should have responded to that.  Given that the meat of this
> series is the first 2 patches (the rest is merely cleaning up the uses of
> the now mulled out macros, right) I think it would have been better (i.e.
> easier for me :-)) if you had a git tree based on v3.10-rc<something> and
> then did a sweep after v3.11-rc1 was out to clean up the rest.

If you'd still rather go that way, then there is such a two patch branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git  cpuinit-delete

Those are the ones that will be (hopefully) added early on in the merge
window anyway.  Note that you'll get a conflict on vmlinux.lds because the
__devinit delete is in Greg's drivers-next tree and not yet mainline.

> > I do not expect any significant changes to the repository going forward.
> > Perhaps adding a couple more "Acked-by:" tags, and dropping a couple
> > patches for when maintainers request to carry them locally.  So I hope
> > it should not be a big burden.  And it is a one-shot tree as well.
> 
> The problem is that it is based on shifting sands i.e. linux-next.  This
> means that I will have to rebase it each day onto the new linux-next just
> before I release it.  I already do this with Andrew's tree and that is a
> bit of a pain already.

Understood.  Feel free to take the two patch approach if it is too much
hassle.  If you do, I will continue to track applicabiliy of the "sweep"
patches locally on your daily linux-next as I had been.

> It also means (given that some linus-next included trees do not actually
> get merged for -rc1), that some of these patches may never apply cleanly
> to Linus' tree.

Yep, but at the same time, linux-next is about 8,000 commits closer to
what the "sweep" patches will be landing on, so I think it was still the
right baseline for me to be doing this work against while we wait for
the merge window.

Thanks for giving the whole series a spin for at least one next tree, as
it probably helped to ensure people are more aware the change is coming.

Paul.
--

> 
> I will try it today and see how we go.  I assume that the current set of
> patches is based on next-20130625?
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au