核心中__init函數的執行順序

在網上搜了一下，沒有很確定的答案，不過一些文章已經有了基本解答了。摘抄如下

參見include/linux/init.h和vmlinux.lds

1）
所有標識為__init的函數在連結的時候都放在.init.text這個區段內，
在這個區段中，函數的擺放順序是和連結的順序有關的，是不確定的。

2）
所有的__init函數在區段.initcall.init中還儲存了一份函數指標，
在初始化時核心會通過這些函數指標調用這些__init函數指標，
並在整個初始化完成後，釋放整個init區段（包括.init.text，.initcall.init等），

注意，這些函數在核心初始化過程中的調用順序只和這裡的函數指標的順序有關，
和1）中所述的這些函數本身在.init.text區段中的順序無關。

在2.4核心中，這些函數指標的順序也是和連結的順序有關的，是不確定的。

在2.6核心中，initcall.init區段又分成7個子區段，分別是
.initcall1.init
.initcall2.init
.initcall3.init
.initcall4.init
.initcall5.init
.initcall6.init
.initcall7.init

當需要把函數fn放到.initcall1.init區段時，只要聲明
core_initcall(fn);
即可。

其他的各個區段的定義方法分別是：
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)。

各個子區段之間的順序是確定的，即先調用.initcall1.init中的函數指標
再調用.initcall2.init中的函數指標，等等。
而在每個子區段中的函數指標的順序是和連結順序相關的，是不確定的。

在核心中，不同的init函數被放在不同的子區段中，因此也就決定了它們的調用順序。
這樣也就解決了一些init函數之間必須保證一定的調用順序的問題。

下面是我自己的一些理解，上面的2.6核心在同一子區段__init函數指標的順序是和連結順序相關的，

那麼連結順序又是怎樣的呢，我覺得是和Makefile中obj-y目標的順序是相關的，為了驗證一下，我在

driver/mtd中mtdcore.c和mtdblock.c的init函數中加了列印語句，先不修改Makefile，其obj-y的順序是

mtdcore.o  mtdblcok.o ,果然列印的順序是mtdcore_init  mtdblock_init ,修改一下Makefile中obj-y的順序

列印的順序也隨之改變，基本驗證也我的想法，不過不能完全確定，呵呵。