From: Jeff Garzik <jgarzik@pobox.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Initcall / device model meltdown?
Date: Fri, 17 Jan 2003 14:32:56 -0500 [thread overview]
Message-ID: <20030117193256.GE8304@gtf.org> (raw)
In-Reply-To: <20030117192356.F13888@flint.arm.linux.org.uk>
On Fri, Jan 17, 2003 at 07:23:56PM +0000, Russell King wrote:
> 1. the device model requires a certain initialisation order.
> 2. modules need to use module_init() which means the initialisation order
> is link-order dependent, despite our multi-level initialisation system.
>
> Obviously one solution would be to spread the drivers for this
> multifunction chip throughout the kernel tree (ie, by function not
> by device) so the touchscreen driver would live under drivers/input.
>
> However, then we need to make sure that the multifunction chip's
> bus type is initialised before any of the other subsystems, and of
> course, the bus type is initialised using module_init() since it
> lives in a module...
>
> I think we need to re-think what we're doing with the initialisation
> handling and the device model before these sorts of problems get out
> of hand.
IMO this link order business is a problem that's existed for ages,
it's unrelated to the device model, and adding seven levels of
initcalls merely hid this problem a little bit.
Back when I was doing fbdev stuff, I just gave up and did things "the
old way", a la
#ifdef MODULE
module_init(my_driver);
#endif
and then call my_driver from other code, when it is built into the
kernel, overriding link order.
Not a great solution, I know. My preferred solution has always been to
explicitly list the dependencies, so a build-time tool can figure out
the link order automagically.
Jeff
next prev parent reply other threads:[~2003-01-17 19:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-17 19:23 Initcall / device model meltdown? Russell King
2003-01-17 19:32 ` Jeff Garzik [this message]
[not found] ` <3104.1042835842@www5.gmx.net>
2003-01-17 20:48 ` Dominik Brodowski
2003-01-17 19:56 ` Kai Germaschewski
2003-01-17 20:14 ` Russell King
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=20030117193256.GE8304@gtf.org \
--to=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.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 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.