阶段一：
kernel-3.18includelinuxinit.h中
Linux内核为不同驱动的加载顺序对应不同的优先级，定义了一些宏：
#define core_initcall(fn) __define_initcall("1",fn,1) //主要的初始化调用 #define core_initcall_sync(fn) __define_initcall("1s",fn,1s) #define postcore_initcall(fn) __define_initcall("2",fn,2) //相对次要的初始化调用 #define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s) #define arch_initcall(fn) __define_initcall("3",fn,3) //与硬件架构相关平台设备的初始化调用 #define arch_initcall_sync(fn) __define_initcall("3s",fn,3s) #define subsys_initcall(fn) __define_initcall("4",fn,4) #define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s) #define fs_initcall(fn) __define_initcall("5",fn,5) #define fs_initcall_sync(fn) __define_initcall("5s",fn,5s) #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs) #define device_initcall(fn) __define_initcall("6",fn,6) #define device_initcall_sync(fn) __define_initcall("6s",fn,6s) #define late_initcall(fn) __define_initcall("7",fn,7) //晚的初始化调用 #define late_initcall_sync(fn) __define_initcall("7s",fn,7s) #define module_init(x)__initcall(x); #define__initcall(fn)device_initcall(fn)
在上面的不同的优先级中，
数字越小，优先级越高。
同一等级的优先级的驱动，加载顺序是链接过程决定的，结果是不确定的，我们无法去手动设置谁先谁后。
不同等级的驱动加载的顺序是先优先级高，后优先级低，这是可以确定的。
所以，late_initcall还要在module_init的后面
所有的__init函数在区段.init.text中，同时还在.initcall.init中还保存了一份函数指针，
在初始化时内核会通过这些函数指针调用这些__init函数指针，
并在整个初始化完成后，释放整个init区段（包括.init.text，.initcall.init等）。
这些函数在内核初始化过程中的调用顺序只和这里的函数指针的顺序有关
中所述的这些函数本身在.init.text区段中的顺序无关。
在2.6内核中，initcall.init区段又分成7个子区段
不同的区段，调用的顺序不一样，数字越小的优先级越高。
阶段二：
在linux系统中：
Linux系统启动过程很复杂，因为它既需要支持模块静态加载机制也要支持动态加载机制insmod。模块动态加载机制给系统提供了极大的灵活性，驱动程序既可支持静态编译进内核，也可以支持动态加载机制。Linux系统中对设备和子系统的初始化在最后进行，主要过程可以用下图表示。
进入子系统初始化时，在内核init进程中进行设备初始化，最为复杂、诡异的机制莫过于do_initcalls()函数调用，该函数完成了所有需要静态加载模块的初始化，需要进行静态加载的内核模块，需要使用一些特定的宏进行处理。
_initcall_start~_initcall_end之间存放：
-
---