解密module_init-embededgood-ChinaUnix博客

__initcall_start是在 arch目录中的相关CPU中的vmlinux.lds文件指定，如i386中位于arch/i386/vmlinux.lds中，至于在__initcall_start和__initcall_end之间的是由函数声明__init指定
2.
察看/arch/i386/vmlinux.lds,发现一段代码
　__initcall_start = .;
　.initcall.init : { *(.initcall.init) }
　__initcall_end = .;
　
跟我找的东西相关
使用info ld,察看相关资料,（最终发现太麻烦，到网上找了一个ld.pdf).发现有这么一
段介绍关于c++地联结构造器的使用，和这段用法相同
其含义时，是让__initcall_start指向代码节.initcall.init的节首，而__initcall_end
指向.initcall.init的节尾。
那么第一段代码从程序逻辑上得到了解释。

3。因为do_initcalls所作的是系统中有关于选择的驱动部分的初始化工作，那么具体是这些
函数指针数据怎样放到了.initcall.init节。
想起来了，还没有使用grep哈哈，在
grep -rn .initcall.init *
发现在include/linux/init.h:83:有这样一个定义
#define __init_call　　 __attribute__ ((unused,__section__ (".initcall.init")))
娃哈哈哈
终于让我发现了
然后又发现了
#define __initcall(fn) \
static initcall_t __initcall_##fn __init_call = fn

4。问题是什么是__attribute__??,查找man gcc,找到关于__attribute__的定义
`section ("section-name")'
　　 Normally, the compiler places the code it generates in the `text'
　　 section.　Sometimes, however, you need additional sections, or you
　　 need certain particular functions to appear in special sections.
　　 The `section' attribute specifies that a function lives in a
　　 particular section.　For example, the declaration:

　　　　　extern void foobar (void) __attribute__ ((section ("bar")));

　　 puts the function `foobar' in the `bar' section.

　　 Some file formats do not support arbitrary sections so the
　　 `section' attribute is not available on all platforms.　If you
　　 need to map the entire contents of a module to a particular
　　 section, consider using the facilities of the linker instead.
　　
他的意思就是使它建造一个在.initcall.init节的指向初始函数的指针

5。问题是##是什么意思？
查阅gcc的man page得知，她是用在可变参数使用宏定义的时候的
在这里也就是建立一个变量名称为所指向的函数的名称，并且前面加上
__initcall_.

6.然后看看成果
在/include/linux/init.c中有发现
#define module_init(x) __initcall(x);
看看很多驱动中都有类似
module_init(usb_init);
module_exit(usb_exit);
的代码，哈哈，这下明白了。

分析kernel的initcall函数
Author: Dongas
Data: 08-07-15

先来看看这些initcall函数的声明：
/* include/linux/init.h */
/* 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.
*/

#define __define_initcall(level,fn) \
   static initcall_t __initcall_##fn __attribute_used__ \
   __attribute__((__section__(".initcall" level ".init"))) = fn

#define core_initcall(fn)       __define_initcall("1",fn)
#define postcore_initcall(fn)       __define_initcall("2",fn)
#define arch_initcall(fn)       __define_initcall("3",fn)
#define subsys_initcall(fn)          __define_initcall("4",fn)
#define fs_initcall(fn)                   __define_initcall("5",fn)
#define device_initcall(fn)          __define_initcall("6",fn)
#define late_initcall(fn)       __define_initcall("7",fn)

#define __initcall(fn) device_initcall(fn)

#define __exitcall(fn) \
   static exitcall_t __exitcall_##fn __exit_call = fn

#define console_initcall(fn) \
   static initcall_t __initcall_##fn \
   __attribute_used__ __attribute__((__section__(".con_initcall.init")))=fn

#define security_initcall(fn) \
   static initcall_t __initcall_##fn \
   __attribute_used__ __attribute__((__section__(".security_initcall.init"))) = fn

#define module_init(x) __initcall(x); ß从这里知道module_init的等级为6，相对靠后
#define module_exit(x)  __exitcall(x);

可以发现这些*_initcall(fn)最终都是通过__define_initcall(level,fn)宏定义生成的。
__define_initcall宏定义如下：
#define __define_initcall(level,fn) \
   static initcall_t __initcall_##fn __attribute_used__ \
   __attribute__((__section__(".initcall" level ".init"))) = fn

这句话的意思为定义一个initcall_t型的初始化函数，函数存放在.initcall”level”.init section内。.initcall”level”.init section定义在vmlinux.lds内。
/* arch/arm/kernel/vmlinux.lds */
……
  __initcall_start = .;
*(.initcall1.init)
*(.initcall2.init)
*(.initcall3.init)
*(.initcall4.init)
*(.initcall5.init)
*(.initcall6.init)
*(.initcall7.init)
  __initcall_end = .;
   ……
正好包括了上面init.h里定义的从core_initcall到late_initcall等7个level等级的.initcall”level”.init section. 因此通过不同的*_initcall声明的函数指针最终都会存放不同level等级的.initcall”level”.init section内。这些不同level的section按level等级高低依次存放。

下面我们再来看看，内核是什么时候调用存储在.initcall”level”.init section内的函数的。

内核是通过do_initcalls函数循环调用执行initcall.init section内的函数的，流程如下：
start_kernel -> rest_init -> kernel_thread -> init -> do_basic_setup -> do_initcalls

这里要分析两个函数: kernel_thread和do_initcalls，这两个函数都定义在init/main.c内
1) kernel_thread
1.static void noinline rest_init(void)
2. __releases(kernel_lock)
3.{
4. system_state = SYSTEM_BOOTING_SCHEDULER_OK;
5.
6. kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
7. numa_default_policy();
8. unlock_kernel();
9.
10.  /*
11.  * The boot idle thread must execute schedule()
12.  * at least one to get things moving:
13.  */
14.  __preempt_enable_no_resched();
15.  schedule();
16.  preempt_disable();
17.
18.  /* Call into cpu_idle with preempt disabled */
19.  cpu_idle();
20.}
第6行通过kernel_thread创建一个内核线程执行init函数。（其实这里创建的即Linux的1号进程(init进程), 为linux中所有其他进程的父进程，有兴趣的可以自己查资料）

2) do_initcalls
1.static void __init do_initcalls(void)
2.{
3. initcall_t *call;
4. int count = preempt_count();
5.
6. for (call = __initcall_start; call
7.          ……
8.          result = (*call)();
9.          ……
10.  }
11.}
其中, initcall_t类型如下：
typedef int (*initcall_t)(void);

__initcall_start和__initcall_end定义在vmlinux.lds内，表示initcall section的起始和结束地址。
/* arch/arm/kernel/vmlinux.lds */
……
  __initcall_start = .;
*(.initcall1.init)
*(.initcall2.init)
*(.initcall3.init)
*(.initcall4.init)
*(.initcall5.init)
*(.initcall6.init)
*(.initcall7.init)
  __initcall_end = .;
   ……
因此，上面6-10行代码的作用为按initcall level等级的顺序，依次循环调用预先存储在initcall section内的所有各个级别的初始化函数。这样，kernel的initcall函数的原理我们就搞清楚了。

最后要注意的是rest_init是在start_kernel函数内最后部分才被调用执行的，rest_init前包含了kernel一系列的初始化工作。另外，这些不同level等级的initcall.init section本身有一定的执行顺序，因此如果你的驱动依赖于特定的执行顺序的话需要考虑到这一点。

initcall机制原理及实践

arm linux启动流程之进入内核

还是从编译链接生成vmlinux的过程来看吧，由一大堆.o文件链接而成，第一个就是
kernel\arch\arm\kernel\head-armv.o ,而且我们还看到了
lds链接文件kernel\arch\arm\vmlinux.lds,先把它分析一下
ENTRY(stext) //入口点是stext 应该就在head-armv.s中了
SECTIONS
{
. = 0xC0008000;  //基址，是内核开始的虚拟地址
.init : { /* Init code and data  */
  _stext = .;
  __init_begin = .;
*(.text.init)
  __proc_info_begin = .;
*(.proc.info)
  __proc_info_end = .;
  __arch_info_begin = .;
*(.arch.info)
  __arch_info_end = .;
  __tagtable_begin = .;
*(.taglist)
  __tagtable_end = .;
*(.data.init)
  . = ALIGN(16);
  __setup_start = .;
*(.setup.init)
  __setup_end = .;
  __initcall_start = .;
*(.initcall.init)
  __initcall_end = .;
  . = ALIGN(4096);
  __init_end = .;
}
关于虚拟地址和物理地址的：使用MMU后，系统就会使用虚拟地址，通过MMU来指向
实际物理地址而在这里我们的0xC0008000实际物理地址就是0x30008000，
具体关于MMU的介绍参考《ARM体系结构与编程》。
到head-armv.s找到程序的入口
  .section ".text.init",#alloc,#execinstr
  .type stext, #function
ENTRY(stext)
  mov r12, r0
  mov r0, #F_BIT | I_BIT | MODE_SVC @ make sure svc mode
  msr cpsr_c, r0 @ and all irqs disabled
  bl __lookup_processor_type
  teq r10, #0 @ invalid processor?
  moveq r0, #'p' @ yes, error 'p'
  beq __error
  bl __lookup_architecture_type
  teq r7, #0 @ invalid architecture?
  moveq r0, #'a' @ yes, error 'a'
  beq __error
  bl __create_page_tables
  adr lr, __ret @ return address
  add pc, r10, #12 @ initialise processor
来看看上一句跳到哪里去了
去追寻r10的值，是在__lookup_processor_type子函数中赋的
__lookup_processor_type:
  adr r5, 2f //r5 标号2的地址基址是0x30008000
  ldmia r5, {r7, r9, r10} //r7=__proc_info_end  r9=__proc_info_begin
  sub r5, r5, r10  //r10 标号2的链接地址基址是0xc0008000
  add r7, r7, r5 @ to our address space
  add r10, r9, r5  //r10 变换为基址是0x30008000的__proc_info_begin
2:  .long __proc_info_end
  .long __proc_info_begin
  .long 2b
这样r10中存放的是__proc_info_begin的地址,因为现在我们还没有打开MMU
所以还是需要把基址变换到0x30008000,接着我们就去找__proc_info_begin吧
注意到在上面的vmlinux.lds中有这个标号,下来链接的是.proc.info段,
在kernel\arch\arm\mm\proc-arm920.s的最后找到了这个段
.section ".proc.info", #alloc, #execinstr
.type __arm920_proc_info,#object
__arm920_proc_info:
.long 0x41009200
.long 0xff00fff0
.long 0x00000c1e @ mmuflags
b __arm920_setup
ok,这样我们就知道add pc, r10, #12跳到哪里去了,因为这个地址刚好放了条跳转语句
注意了b语句用的都是相对地址,所以不需要变换地址,反正是跳到__arm920_setup,而且
上一条语句是adr lr, __ret,设定了__arm920_setup的返回地址是__ret,所以执行完
__arm920_setup后回到head-armv.s的__ret标号继续执行.
__ret:  ldr lr, __switch_data
  mcr p15, 0, r0, c1, c0 //注意这里了,在这里打开了MMU
  mov r0, r0
  mov r0, r0
  mov r0, r0
  mov pc, lr //跳到__mmap_switched,这里已经用了虚拟地址了吧
// 这条指令ldr lr, __switch_data加载的__mmap_switched地址就是虚拟地址啊
__switch_data: .long __mmap_switched
从__mmap_switched一路执行下来,就要调到C语言代码中去了
  b SYMBOL_NAME(start_kernel) //在kernel\init\main.c中
这个程序不是特别复杂，细心看看还是能大概看懂，我也不能去一一注释
这里有一个流程图

到了C语言中就不是很难理解了
lock_kernel();
printk(linux_banner);
setup_arch(&command_line);
printk("Kernel command line: %s\n", saved_command_line);
parse_options(command_line);
trap_init();
init_IRQ();
sched_init();
softirq_init();
time_init();
就是一大堆初始化工作,追着每个函数去看好了
start_kernel最后调用的一个函数
static void rest_init(void)
{
kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
unlock_kernel();
current->need_resched = 1;
  cpu_idle();
}
用kernel_thread建立了一个init进程,执行的是main.c中的init函数
lock_kernel();
do_basic_setup();
在do_basic_setup中调用了do_initcalls函数
各种驱动都是在do_initcalls(void)中完成的
static void __init do_initcalls(void)
{
initcall_t *call;
call = &__initcall_start;
do {
  (*call)();
  call++;
} while (call
flush_scheduled_tasks();
}
__initcall_start也是在vmlinux.lds中赋值的,那就需要找到.initcall.ini这个段
在kernel\include\linux\init.h中可以找到
#define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
typedef int (*initcall_t)(void);
#define __initcall(fn)       \
static initcall_t __initcall_##fn __init_call = fn
仔细研究下就发现这是把初始化函数的地址放到了.initcall.init段中
这样就可以不断调用驱动的初始化函数了
如果没有定义MODULE,那么#define module_init(x) __initcall(x);
所以如果要把驱动的编译进内核就很简单了吧
init的最后
if (execute_command)
  execve(execute_command,argv_init,envp_init);
execute_command与ppcboot传的命令行参数是有关的哦,就是init=/linuxrc
这样就要去执行根目录下的linuxrc脚本,这个脚本会去执行busybox
而busybox又去执行/etc/init.d/rcS脚本,这个脚本又去执行/usr/etc/rc.local
完了