标签：style blog color os 使用 ar strong 文件 sp
Linux系统使用两种方式去加载系统中的模块：动态和静态。
静态加载：将所有模块的程序编译到Linux内核中，由do_initcall函数加载
核心进程（/init/main.c）kernel_init do_basic_setup() do_initcalls（）该函数中会将在__initcall_start和__initcall_end之间定 义的各个模块依次加载。那么在__initcall_start 和 __initcall_end之间都有些什么呢？
找到/arch/powerpc/kernel/vmlinux.lds文件，找到.initcall.init段：
.initcall.init : { __initcall_start = .; *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init) __initcall_end = .; }
也就是说14个宏有优先级：0>1>1s>2>2s………>7>7s
#define pure_initcall(fn) __define_initcall("0",fn,0) #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)
module_init = device_initcall
动态加载：模块初始化函数都用module_init(fn)声明的话，如果一个子系统下有两个module_init(fn)，则这两个初始化函数的执行顺序只跟链接顺序有关。
即，此时顺序与Makefile文件中的排序有关。
obj-y += ‘先调用module_init‘/ obj-y += ‘后调用module_init‘/
标签：style blog color os 使用 ar strong 文件 sp
原文地址：http://www.cnblogs.com/lvzaina/p/4024953.html
