All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org, rpjday@crashcourse.ca,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [patch 3/4] macintosh: replace deprecated __initcall with device_initcall
Date: Thu, 15 May 2008 10:43:02 -0700	[thread overview]
Message-ID: <20080515104302.1b78e522.akpm@linux-foundation.org> (raw)
In-Reply-To: <1210842517.17568.41.camel@localhost>

On Thu, 15 May 2008 19:08:37 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:

> On Wed, 2008-05-14 at 23:41 -0700, Andrew Morton wrote:
> > On Thu, 15 May 2008 16:28:28 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> > 
> > > On Wed, 2008-05-14 at 23:06 -0700, Andrew Morton wrote:
> > > > On Thu, 15 May 2008 14:14:38 +1000 Paul Mackerras <paulus@samba.org> wrote:
> > > > 
> > > > > akpm@linux-foundation.org writes:
> > > > > 
> > > > > > -__initcall(adb_init);
> > > > > > +device_initcall(adb_init);
> > > > > 
> > > > > There's no particular reason why this needs to go in 2.6.26, is there?
> > > > > It looks to me like something that I should queue up for 2.6.27.
> > > > > 
> > > > 
> > > > No, this make no difference in code generation - it's just a
> > > > use-the-modern-interface thing.
> > > 
> > > I missed the memo about __initcall being deprecated, or is it only
> > > deprecated for use in device drivers?
> > > 
> > 
> > It's just old-fashioned, that's all.
> >
> > #define pure_initcall(fn)		__define_initcall("0",fn,0)
> > 
> > #define core_initcall(fn)		__define_initcall("1",fn,1)
> > #define core_initcall_sync(fn)		__define_initcall("1s",fn,1s)
> > #define postcore_initcall(fn)		__define_initcall("2",fn,2)
> > #define postcore_initcall_sync(fn)	__define_initcall("2s",fn,2s)
> > #define arch_initcall(fn)		__define_initcall("3",fn,3)
> > #define arch_initcall_sync(fn)		__define_initcall("3s",fn,3s)
> > #define subsys_initcall(fn)		__define_initcall("4",fn,4)
> > #define subsys_initcall_sync(fn)	__define_initcall("4s",fn,4s)
> > #define fs_initcall(fn)			__define_initcall("5",fn,5)
> > #define fs_initcall_sync(fn)		__define_initcall("5s",fn,5s)
> > #define rootfs_initcall(fn)		__define_initcall("rootfs",fn,rootfs)
> > #define device_initcall(fn)		__define_initcall("6",fn,6)
> > #define device_initcall_sync(fn)	__define_initcall("6s",fn,6s)
> > #define late_initcall(fn)		__define_initcall("7",fn,7)
> > #define late_initcall_sync(fn)		__define_initcall("7s",fn,7s)
> > 
> > #define __initcall(fn) device_initcall(fn)
> > 
> > See, we have the nicely-ordered foo_initcall()'s, and the old-fashioned
> > legacy __initcall happens to map onto device_initcall().
> > 
> > Such code should use device_initcall() directly.  So we see at which
> > stage in initcalls this function will be called.
> 
> Yeah fair enough. 
> 
> A little git'ing tells me there were 31 new __initcall()'s added between
> 2.6.24 and 2.6.25, and there are 12 more lurking between 2.6.25 and
> linux-next. They're breeding!
> 
> You can't stick a #warning inside a #define can you? How about:
> 
> #define __initcall(fn)				\
> do {						\
> int Use_device_initcall_not___initcall_please;	\
> device_initcall(fn);				\
> } while (0)
> 
> Which gives:
> warning: unused variable ______Use_device_initcall_not___initcall_please___
> 
> ..
> 
> Yeah OK that was a joke.

I'm sure Andy can give us a checkpatch warning when someone uses
__initcall.  That'll help a bit.

      reply	other threads:[~2008-05-15 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 23:12 [patch 3/4] macintosh: replace deprecated __initcall with device_initcall akpm
2008-05-15  4:14 ` Paul Mackerras
2008-05-15  6:06   ` Andrew Morton
2008-05-15  6:28     ` Michael Ellerman
2008-05-15  6:41       ` Andrew Morton
2008-05-15  9:08         ` Michael Ellerman
2008-05-15 17:43           ` Andrew Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080515104302.1b78e522.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=rpjday@crashcourse.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.