所有的__init函數(shù)在區(qū)段.initcall.init中還保存了一份函數(shù)指針，在初始化時內(nèi)核會通過這些函數(shù)指針調(diào)用這些__init函數(shù)指針，并在整個初始化完成后，釋放整個init區(qū)段（包括.init.text，.initcall.init等）。

注意，這些函數(shù)在內(nèi)核初始化過程中的調(diào)用順序只和這里的函數(shù)指針的順序有關，和1）中所述的這些函數(shù)本身在.init.text區(qū)段中的順序無關。在2.4內(nèi)核中，這些函數(shù)指針的順序也是和鏈接的順序有關的，是不確定的。在2.6內(nèi)核中，initcall.init區(qū)段又分成7個子區(qū)段，分別是

.initcall1.init .initcall2.init .initcall3.init .initcall4.init .initcall5.init .initcall6.init .initcall7.init

當需要把函數(shù)fn放到.initcall1.init區(qū)段時，只要聲明

core_initcall(fn);

即可。

其他的各個區(qū)段的定義方法分別是：

core_initcall(fn) --->.initcall1.init postcore_initcall(fn) --->.initcall2.init arch_initcall(fn) --->.initcall3.init subsys_initcall(fn) --->.initcall4.init fs_initcall(fn) --->.initcall5.init device_initcall(fn) --->.initcall6.init late_initcall(fn) --->.initcall7.init

而與2.4兼容的initcall(fn)則等價于device_initcall(fn)。各個子區(qū)段之間的順序是確定的，即先調(diào)用.initcall1.init中的函數(shù)指針，再調(diào)用.initcall2.init中的函數(shù)指針，等等。而在每個子區(qū)段中的函數(shù)指針的順序是和鏈接順序相關的，是不確定的。

在內(nèi)核中，不同的init函數(shù)被放在不同的子區(qū)段中，因此也就決定了它們的調(diào)用順序。這樣也就解決了一些init函數(shù)之間必須保證一定的調(diào)用順序的問題。按照include/linux/init.h文件所寫的，我在驅(qū)動里償試了這樣兩種方式：

__define_initcall("7", fn); late_initcall(fn);

都可以把我的驅(qū)動調(diào)整到最后調(diào)用。實際上上面兩個是一回事：

#define late_initcall(fn) __define_initcall("7", fn)　linux 2.6中把initcall又分成了若干種類，主要用來區(qū)別不同的initcall的調(diào)用次序，由于initcall中的調(diào)用次序是隨機的，所以不能保證某些重要的初始化先運行?！　》殖闪艘韵聨讉€initcall,按執(zhí)行順序先后排列：　　pure_initcall：最先運行的，不依賴于任何其他初始化函數(shù)。　　core_initcall　　core_initcall_sync　　postcore_initcall　　postcore_initcall_sync　　arch_initcall　　arch_initcall_sync　　subsys_initcall　　subsys_initcall_sync　　fs_initcall　　fs_initcall_sync　　rootfs_initcall　　device_initcall　　device_initcall_sync　　late_initcall　　late_initcall_sync　　可以看一下些x86中pci初始化的代碼，首先是pci_access_init，這個函數(shù)是arch_initcall的，然后是pci_legacy_init，這個函數(shù)是subsys_initcall的，然后是pcibios_irq_init，這個函數(shù)也是subsys_initcall的，然后是pcibios_assign_resources這個函數(shù)是fs_initcall的，最后才是pci_init，這個函數(shù)是device_initcall的，這樣就把整個pci初始化過程分開了。
?