关于linux 内核中的initcall

找了一个相对比较浅显易懂的，转了下来。
如下：
参考：http://blog.163.com/gpg119/blog/static/9153415320089824938513/
late_initcall  

    所有的__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函数之间必须保证一定的调用顺序的问题。按照include/linux/init.h文件所写的，我在驱动里偿试了这样两种方式：
__define_initcall("7", fn);
late_initcall(fn);

　　都可以把我的驱动调整到最后调用。实际上上面两个是一回事：
#define late_initcall(fn) __define_initcall("7", fn)

　linux 2.6中把initcall又分成了若干种类，主要用来区别不同的initcall的调用次序，由于initcall中的调用次序是随机的，所以不能保证某些重要的初始化先运行。

　　分成了以下几个initcall,按执行顺序先后排列：
　　pure_initcall：最先运行的，不依赖于任何其他初始化函数。
　　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，这个函数是arch_initcall的，然后是pci_legacy_init，这个函数是subsys_initcall的，然后是pcibios_irq_init，这个函数也是subsys_initcall的，然后是pcibios_assign_resources这个函数是fs_initcall的，最后才是pci_init，这个函数是device_initcall的，这样就把整个pci初始化过程分开了。