本文適用于
ADSP-BF561
uclinux-2008r1.5-rc3 (smp patch)
Visual DSP++ 5.0(update 5)
在內(nèi)核中有許多的驅動，這些驅動之間有一些具有依賴關系，那么內(nèi)核是如何控制它們之間的調用順序的呢？
內(nèi)核中的驅動通常會使用module_init這樣的宏來指定驅動的初始化函數(shù)。那么module_init是什么東西呢？
在include/linux/init.h中提供了它的定義：
typedef int (*initcall_t)(void);
/**
* module_init() - driver initialization entry point
* @x: function to be run at kernel boot time or module insertion
*
* module_init() will either be called during do_initcalls() (if
* builtin) or at module insertion time (if a module). There can only
* be one per module.
*/
#define module_init(x) __initcall(x);
在init.h中很容易可以發(fā)現(xiàn)一些類似的定義：
/* initcalls are now grouped by functionality into separate
* subsections. Ordering inside the subsections is determined
* by link order.
* For backwards compatibility, initcall() puts the call in
* the device init subsection.
*
* The `id' arg to __define_initcall() is needed so that multiple initcalls
* can point at the same handler without causing duplicate-symbol build errors.
*/
#define __define_initcall(level,fn,id) /
static initcall_t __initcall_##fn##id __attribute_used__ /
__attribute__((__section__(".initcall" level ".init"))) = fn
/*
* A "pure" initcall has no dependencies on anything else, and purely
* initializes variables that couldn't be statically initialized.
*
* This only exists for built-in code, not for modules.
*/
#define pure_initcall(fn) __define_initcall("0",fn,1)
#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 __initcall(fn) device_initcall(fn)
可以看到，通過__attribute__的控制，不同的函數(shù)指針將放在不同的段中，而這些段名稱的規(guī)則為：
".initcall" level ".init"
在vmlinux.lds.s中為這些段指定了存儲空間：
.initcall.init :
{
___initcall_start = .;
INITCALLS
___initcall_end = .;
}
這里的INITCALLS是一個宏定義：
#define INITCALLS /
*(.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)
也就是說，在鏈接器的安排下，這些不同level的調用函數(shù)將按照從小到大的順序排列。
在內(nèi)核初始化的時候會調用一個叫do_initcalls的函數(shù)：
extern initcall_t __initcall_start[], __initcall_end[];
static void __init do_initcalls(void)
{
initcall_t *call;
int count = preempt_count();
for (call = __initcall_start; call < __initcall_end; call++) {
……………….
result = (*call)();
………………
}
/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_work();
}
就這樣，內(nèi)核達到了按指定順序調用函數(shù)的目的。 |
