Re: How to understand flow of kernel code

[David Eger <eger@havoc.gtf.org>]

One of the more bizarre details of kernel initialization is in
do_initcalls().  It's one of the last things in the initialization
sequence that you see code for, and it does some odd function-pointer
table assembly hackery.  You don't actually see a list of the functions
that do_initcalls() calls because *it's generated at compile time*.
Each module/filesystem/arch/etc can register an initialization function
with the build system through a declaration like the following in
"binfmt_elf.c":

core_initcall(init_elf_binfmt);

This macro is defined in init.h, along with several others:

#define core_initcall(fn)               __define_initcall("1",fn)
#define postcore_initcall(fn)           __define_initcall("2",fn)
#define arch_initcall(fn)               __define_initcall("3",fn)
#define subsys_initcall(fn)             __define_initcall("4",fn)
#define fs_initcall(fn)                 __define_initcall("5",fn)
#define device_initcall(fn)             __define_initcall("6",fn)
#define late_initcall(fn)               __define_initcall("7",fn)

When the build system is done building all the files, it gathers together
all of the special initcall declarations and links them into one table:
the one that do_initcalls() iterates over.

-dte