From: Russell King <rmk@arm.linux.org.uk>
To: Patrick Mochel <mochel@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Defining new section for bus driver init
Date: Tue, 15 Jan 2002 10:00:41 +0000 [thread overview]
Message-ID: <20020115100041.A994@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.33.0201141746000.827-100000@segfault.osdlab.org>
In-Reply-To: <Pine.LNX.4.33.0201141746000.827-100000@segfault.osdlab.org>; from mochel@osdl.org on Mon, Jan 14, 2002 at 05:47:15PM -0800
On Mon, Jan 14, 2002 at 05:47:15PM -0800, Patrick Mochel wrote:
> Attached is a patch that creates a new section for device subsystem init
> calls. With it, the root bus init calls are handled just like init calls
> - the section consists of a table of function pointers.
> device_driver_init() iterates over that table and calls each one.
> (device_driver_init() currently happens just before that pci_init() call
> above).
I've been thinking about this, and would like to suggest something that'd
reduce the code size, but is dependent on the ordering of stuff in
do_basic_setup. So first some questions. Currently, we do:
device_driver_init()
random bus driver init...
sock_init()
start_context_thread()
do_initcalls()
Is there any ordering dependency between sock_init(), start_context_thread()
and the bus driver init calls? From a brief look at the code, it would
appear that start_context_thread() is rather safe, but sock_init() is
questionable. If they are both safe, then we could move these two calls
before, or even just after device_driver_init():
device_driver_init()
sock_init()
start_context_thread()
random bus driver init...
do_initcalls()
Now we have the bus driver initialisation and the initcall initialisation
next to each other. We can then pull this trick with the linker file:
__initcall_start = .;
.initcall : {
*(.devsubsys.init)
*(.initcall.init)
}
__initcall_end = .;
All the magic then happens within do_initcalls() without any extra code
needing to be added. The really funky thing about this approach is
that you can add other sections to handle network protocol modules
and such like with virtually zero code.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2002-01-15 10:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-15 1:47 Defining new section for bus driver init Patrick Mochel
2002-01-15 10:00 ` Russell King [this message]
2002-01-15 18:02 ` Patrick Mochel
-- strict thread matches above, loose matches on Subject: below --
2002-01-15 2:55 Dave Jones
2002-01-15 17:50 ` Patrick Mochel
[not found] <20020115050512.GA24580@kroah.com>
2002-01-15 17:53 ` Patrick Mochel
2002-01-15 18:07 ` Dave Jones
2002-01-15 19:43 ` Patrick Mochel
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=20020115100041.A994@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.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