mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] automatic module_init ordering
Date: Wed, 07 Aug 2002 21:10:59 +1000	[thread overview]
Message-ID: <20020807112033.00F0E4536@lists.samba.org> (raw)
In-Reply-To: Your message of "Wed, 07 Aug 2002 12:40:22 +0200." <Pine.LNX.4.44.0208071208210.28515-100000@serv>

In message <Pine.LNX.4.44.0208071208210.28515-100000@serv> you write:
> Hi,
> 
> On Wed, 7 Aug 2002, Rusty Russell wrote:
> 
> > suspend/wakeup is a device issue, solved well by devicefs.  This is
> > completely independent from the subtleties of initialization order in
> > the core kernel code: devices are not the problem.
> 
> If you see the pci code as a bus device driver, it becomes a problem. I
> looked at the remaining initcalls in my kernel and most of them are for
> pci. I think pci is rather abusing the initcall system.
> I have that idea that pci (like other buses) could become a "normal"
> driver module (one will probably never compile it as a module, but one
> could at least manage it like one).
> So if we integrate the bus initalizations into the device initializations,
> there isn't much left of the current initcalls.

Yes, that's a very astute observation about PCI.  But we will still
have the hard ones left, like the initcalls which want to be called
before SMP, or two-sided registration mechanisms (anything which has
registration of servers and clients) still requires ordering.

> > I really want *one* place where you can see what order things are
> > initalized.  If that means one big file with #ifdef's, fine.  But the
> > current approach of using link order, initializer levels and explicit
> > initializers is really hard to debug and modify.
> 
> I agree that it's currently a mess, maybe your solution is the better in
> the short term to make the dependencies explicit, I'm not sure about that.
> My idea is to handle as much as possible over the module/driver
> initialization mechanisms and leave initcalls as special cases.

The best thing about the explicit initcalls is that they document
everything they are relying on, so they can be replaced.  At the
moment it's very hard to see how to replace an initcall (does it rely
on link order for example).

I don't think we can complete the conversion before 2.6, so I think we
need both.  If explicit core initcalls become v. rare, great!

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  reply	other threads:[~2002-08-07 11:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-01 23:52 Roman Zippel
2002-08-02  3:19 ` Kai Germaschewski
2002-08-02 21:22   ` Sam Ravnborg
2002-08-03  1:17     ` Kai Germaschewski
2002-08-03 22:11       ` Sam Ravnborg
2002-08-04 15:30         ` Roman Zippel
2002-08-04 20:04           ` Sam Ravnborg
2002-08-04 20:10             ` Sam Ravnborg
2002-08-05  6:13           ` Rusty Russell
2002-08-05 19:05             ` Roman Zippel
2002-08-06  7:28               ` Rusty Russell
2002-08-06 18:57                 ` Roman Zippel
2002-08-07  1:05                   ` Rusty Russell
2002-08-07  2:28                     ` Kai Germaschewski
2002-08-07 10:40                     ` Roman Zippel
2002-08-07 11:10                       ` Rusty Russell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-29 23:46 [PATCH] automatic initcalls Rusty Russell
2002-07-30 23:04 ` [PATCH] automatic module_init ordering Roman Zippel
2002-07-31  2:33   ` Kai Germaschewski
2002-07-31  3:26     ` Rusty Russell
2002-07-31 17:06       ` Kai Germaschewski
2002-07-31 23:28         ` Rusty Russell

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=20020807112033.00F0E4536@lists.samba.org \
    --to=rusty@rustcorp.com.au \
    --cc=kai@tp1.ruhr-uni-bochum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@linux-m68k.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®