From: Roman Zippel <zippel@linux-m68k.org>
To: Patrick Mochel <mochel@osdl.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel <linux-kernel@vger.kernel.org>,
Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] automatic initcalls
Date: Mon, 29 Jul 2002 22:14:13 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.44.0207292134480.28515-100000@serv> (raw)
In-Reply-To: <Pine.LNX.4.44.0207291142120.22697-100000@cherise.pdx.osdl.net>
Hi,
On Mon, 29 Jul 2002, Patrick Mochel wrote:
> > > -__initcall(spawn_ksoftirqd);
> > > +fs_initcall(spawn_ksoftirqd);
> >
> > See, this is exacly the kind of thing that makes me doubt that the
> > current "magic 7 initcall levels" are useful in the long term 8(
>
> I agree that that is abusing the interface. WTF does spawn_ksoftirqd have
> to do with filesystems?
Above is just a hack to get it working, I only moved it one level up,
instead of spending too much time on figuring out the complete
dependencies.
> The purpose of the initcall levels in the first place was to start
> removing the ugly conditional calls in init/main.c I looked at what was
> being called, and came up with names to describe what was being done at
> each phase. There happened to be seven of them.
I think we should separate module initialization from this, as these can
be automatically ordered, what the posted patch demonstrates.
The initcall mechanism would then only be needed to initialize core kernel
services, which can't be build as module.
I'm only interrested to get the module initialization right, because
otherwise I get problems with the new module interface. I want to avoid
to include an explicit ordering, but currently some modules make use of
that *_initcall is mapped to module_init if compiled as module (e.g. usb
or pcmcia).
bye, Roman
prev parent reply other threads:[~2002-07-29 20:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-27 20:22 Roman Zippel
2002-07-28 3:31 ` Rusty Russell
2002-07-28 3:51 ` Jeff Garzik
2002-07-28 4:47 ` Linus Torvalds
2002-07-28 8:50 ` Keith Adamson
2002-07-28 18:59 ` Oliver Xymoron
2002-07-29 23:39 ` Rusty Russell
2002-07-29 8:39 ` Ingo Oeser
2002-07-30 2:49 ` Keith Adamson
2002-07-30 2:51 ` Keith Adamson
2002-07-28 12:18 ` Roman Zippel
2002-07-29 23:46 ` 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
2002-07-28 21:59 ` [PATCH] automatic initcalls Kai Germaschewski
2002-07-29 18:56 ` Patrick Mochel
2002-07-29 20:14 ` Roman Zippel [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=Pine.LNX.4.44.0207292134480.28515-100000@serv \
--to=zippel@linux-m68k.org \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.com \
/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®