Re: Defining new section for bus driver init

Russell King (rmk@arm.linux.org.uk)
Tue, 15 Jan 2002 10:00:41 +0000


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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/