zImage是ARM
Linux常用的一种压缩映像文件，uImage是U-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的“头”，说明这个映像文
件的类型、加载位置、生成时间、大小等信息。换句话说，如果直接从uImage的0x40位置开始执行，zImage和uImage没有任何区别。另外，
Linux2.4内核不支持uImage，Linux2.6内核加入了很多对嵌入式系统的支持，但是uImage的生成也需要设置。
内核编译完成后会生成zImage内核镜像文件。关于bootloader加载zImage到内核，并且
跳转到zImage开始地址运行zImage的过程，相信大家都很容易理解。但对于zImage是如何解压的过程，就不是那么好理解了。本文将结合部分关
键代码，讲解zImage的解压过程。
$(addprefix $(obj)/, $(OBJS)) FORCE
其中Image是由内核顶层目录下的vmlinux二进制化后得到的。注意：arch/arm/boot/compressed/vmlinux是位置无关的，这个有助于理解后面的代码。，链接选项中有个 –fpic参数：
下面就要看内核的启动了，那么内核是从什么地方开始运行的呢？这个当然要看lds文件啦。zImage的
生成经历了两次大的链接过程：一次是顶层vmlinux的生成，由arch/arm/boot/vmlinux.lds（这个lds文件是由
arch/arm/kernel/vmlinux.lds.S生成的）决定；另一次是arch/arm/boot/compressed/vmlinux
的生成，是由arch/arm/boot/compressed/vmlinux.lds（这个lds文件是由
arch/arm/boot/compressed/vmlinux.lds.in生成的）决定。zImage的入口点应该由
arch/arm/boot/compressed/vmlinux.lds决定。从中可以看出入口点为‘_start’
. = 0;
再看看misc.c中decompress_kernel函数吧，它将调用gunzip()解压内核。gunzip()在lib/inflate.c中定义，它将调用NEXTBYTE()，进而调用get_byte()来获取压缩内核代码。
从zImage头跳转进来，此时的状态
- MMU为off
- D-cache为off
- I-cache为dont care，on或off没有关系
- r0为0
- r1为machine ID
- r2为atags指针
内核
代码入口在linux
-2.6.24-moko-linuxbj/arch/arm
/kernel/head.S文件的83行。首先进入SVC32模式，并查询CPU ID，检查合法性
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
@ and irqs disabled
mrc p15, 0, r9, c0, c0 @ get processor id
bl __lookup_processor_type @ r5=procinfo r9=cpuid
movs r10, r5 @ invalid processor (r5=0)?
beq __error_p @ yes, error 'p'
接着在87行进一步查询machine ID并检查合法性
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error 'a'
其中__lookup_processor_type在linux
-2.6.24-moko-linuxbj/arch/arm
/kernel/head
-common.S文件的149行，该函数首将标号3的实际地址加载到r3，然后将编译时生成的__proc_info_begin虚拟地址载入到r5，
__proc_info_end虚拟地址载入到r6，标号3的虚拟地址载入到r7。由于adr伪指令和标号3的使用，以及
__proc_info_begin等符号在linux
-2.6.24-moko-linuxbj/arch/arm
/kernel/vmlinux.lds而不是代码中被定义，此处代码不是非常直观，想弄清楚代码缘由的读者请耐心阅读这两个文件和adr伪指令的说明。
r3和r7分别存储的是同一位置标号3的物理地址（由于没有启用mmu，所以当前肯定是物理地址）和虚拟地址，所以儿者相减即得到虚拟地址和物理地址之间的offset。利用此offset，将r5和r6中保存的虚拟地址转变为物理地址
__lookup_processor_type:
adr r3, 3f
ldmda r3, {r5 - r7}
sub r3, r3, r7 @ get offset between virt&phys
add r5, r5, r3 @ convert virt addresses to
add r6, r6, r3 @ physical address space
然后从proc_info中读出内核
编译时写入的processor ID和之前从cpsr中读到的processor ID对比，查看代码和CPU硬件是否匹配（想在arm920t上运行为cortex-a8编译的内核
？不让！）。如果编译了多种处理器支持，如versatile板，则会循环每种type依次检验，如果硬件读出的ID在内核
中找不到匹配，则r5置0返回
1: ldmia r5, {r3, r4} @ value, mask
and r4, r4, r9 @ mask wanted bits
teq r3, r4
beq 2f
add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list)
cmp r5, r6
blo 1b
mov r5, #0 @ unknown processor
2: mov pc, lr
__lookup_machine_type在linux
-2.6.24-moko-linuxbj/arch/arm
/kernel/head-common.S文件的197行，编码方法与检查processor ID完全一样，请参考前段
__lookup_machine_type:
adr r3, 3b
ldmia r3, {r4, r5, r6}
sub r3, r3, r4 @ get offset between virt&phys
add r5, r5, r3 @ convert virt addresses to
add r6, r6, r3 @ physical address space
1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type
teq r3, r1 @ matches loader number?
beq 2f @ found
add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc
cmp r5, r6
blo 1b
mov r5, #0 @ unknown machine
2: mov pc, lr
代码回到head.S第92行，检查atags合法性，然后创建初始页表
bl __vet_atags
bl __create_page_tables
创建页表的代码在218行，首先将内核
起始地址-0x4000到内核
起始地址之间的16K存储器清0
__create_page_tables:
pgtbl r4 @ page table address
/*
* Clear the 16K level 1 swapper page table
*/
mov r0, r4
mov r3, #0
add r6, r0, #0x4000
1: str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
teq r0, r6
bne 1b
然后在234行将proc_info中的mmu_flags加载到r7
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
在242行将PC指针右移20位，得到内核
第一个1MB空间的段地址存入r6，在s3c2410平台该值是0x300。接着根据此值存入映射标识
mov r6, pc, lsr #20 @ start of kernel section
orr r3, r7, r6, lsl #20 @ flags + kernel base
str r3, [r4, r6, lsl #2] @ identity mapping
完成页表设置后回到102行，为打开虚拟地址映射作准备。设置sp指针，函数返回地址lr指向__enable_mmu，并跳转到linux
-2.6.24-moko-linuxbj/arch/arm
/mm/proc-arm920.S的386行，清除I-cache、D-cache、write buffer和TLB
__arm920_setup:
mov r0, #0
mcr p15, 0, r0, c7, c7 @ invalidate I,D caches on v4
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer on v4
#ifdef CONFIG_MMU
mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs on v4
#endif
然后返回head.S的158行，加载domain和页表，跳转到__turn_mmu_on
__enable_mmu:
#ifdef CONFIG_ALIGNMENT_TRAP
orr r0, r0, #CR_A
#else
bic r0, r0, #CR_A
#endif
#ifdef CONFIG_CPU_DCACHE_DISABLE
bic r0, r0, #CR_C
#endif
#ifdef CONFIG_CPU_BPREDICT_DISABLE
bic r0, r0, #CR_Z
#endif
#ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
#endif
mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | /
domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | /
domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | /
domain_val(DOMAIN_IO, DOMAIN_CLIENT))
mcr p15, 0, r5, c3, c0, 0 @ load domain access register
mcr p15, 0, r4, c2, c0, 0 @ load page table pointer
b __turn_mmu_on
在194行把mmu使能位写入mmu，激活虚拟地址。然后将原来保存在sp中的地址载入pc，跳转到head-common.S的__mmap_switched，至此代码进入虚拟地址的世界
mov r0, r0
mcr p15, 0, r0, c1, c0, 0 @ write control reg
mrc p15, 0, r3, c0, c0, 0 @ read id reg
mov r3, r3
mov r3, r3
mov pc, r13
在head-common.S的37行开始清除内核
bss段，processor ID保存在r9，machine ID报存在r1，atags地址保存在r2，并将控制寄存器保存到r7定义的内存地址。接下来跳入linux
-2.6.24-moko-linuxbj/init/main.c的507行，start_kernel函数。这里只粘贴部分代码
__mmap_switched:
adr r3, __switch_data + 4
ldmia r3!, {r4, r5, r6, r7}
cmp r4, r5 @ Copy data segment if needed
1: cmpne r5, r6
ldrne fp, [r4], #4
strne fp, [r5], #4
bne 1b
在main.c第507行，是硬件无关的C初始化代码
asmlinkage void __init start_kernel(void)
{
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];
smp_setup_processor_id();
s3c2410平台linux
-2.6.24内核
早期的汇编初始化到这里就结束了
start_kernel()中调用了一系列初始化函数，以完成kernel本身的设置。
这些动作有的是公共的，有的则是需要配置的才会执行的。
在start_kernel()函数中，
- 输出Linux版本信息（printk(linux_banner)）
- 设置与体系结构相关的环境（setup_arch()）
- 页表结构初始化（paging_init()）
-
使用"arch/alpha/kernel/entry.S"中的入口点设置系统自陷入口（trap_init()）
- 使用alpha_mv结构和entry.S入口初始化系统IRQ（init_IRQ()）
-
核心进程调度器初始化（包括初始化几个缺省的Bottom-half，sched_init()）
-
时间、定时器初始化（包括读取CMOS时钟、估测主频、初始化定时器中断等，time_init()）
-
提取并分析核心启动参数（从环境变量中读取参数，设置相应标志位等待处理，（parse_options()）
- 控制台初始化（为输出信息而先于PCI初始化，console_init()）
- 剖析器数据结构初始化（prof_buffer和prof_len变量）
- 核心Cache初始化（描述Cache信息的Cache，kmem_cache_init()）
-
延迟校准（获得时钟jiffies与CPU主频ticks的延迟，calibrate_delay()）
- 内存初始化（设置内存上下界和页表项初始值，mem_init()）
-
创建和设置内部及通用cache（"slab_cache"，kmem_cache_sizes_init()）
- 创建uid taskcount SLAB
cache（"uid_cache"，uidcache_init()）
- 创建文件cache（"files_cache"，filescache_init()）
- 创建目录cache（"dentry_cache"，dcache_init()）
-
创建与虚存相关的cache（"vm_area_struct"，"mm_struct"，vma_init()）
-
块设备读写缓冲区初始化（同时创建"buffer_head"cache用户加速访问，buffer_init()）
- 创建页cache（内存页hash表初始化，page_cache_init()）
- 创建信号队列cache（"signal_queue"，signals_init()）
- 初始化内存inode表（inode_init()）
- 创建内存文件描述符表（"filp_cache"，file_table_init()）
- 检查体系结构漏洞（对于alpha，此函数为空，check_bugs()）
-
SMP机器其余CPU（除当前引导CPU）初始化（对于没有配置SMP的内核，此函数为空，smp_init()）
-
启动init过程（创建第一个核心线程，调用init()函数，原执行序列调用cpu_idle()
等待调度，init()）
至此start_kernel()结束，基本的核心环境已经建立起来了。
对于I386平台
i386平台上的内核启动过程与此基本相同，所不同的主要是实现方式。
对于2.4.x版内核
2.4.x中变化比较大，但基本过程没变，变动的是各个数据结构的具体实现，比如Cache。
外设初始化--内核引导第二部分
init()函数作为核心线程，首先锁定内核（仅对SMP机器有效），然后调用
do_basic_setup()完成外设及其驱动程序的加载和初始化。过程如下：
- 总线初始化（比如pci_init()）
-
网络初始化（初始化网络数据结构，包括sk_init()、skb_init()和proto_init()三部分，在proto_init()中，将调用protocols结构中包含的所有协议的初始化过程，sock_init()）
-
创建bdflush核心线程（bdflush()过程常驻核心空间，由核心唤醒来清理被写过的内存缓冲区，当bdflush()由kernel_thread()启动后，它将自己命名为kflushd）
-
创建kupdate核心线程（kupdate()过程常驻核心空间，由核心按时调度执行，将内存缓冲区中的信息更新到磁盘中，更新的内容包括超级块和inode表）
-
设置并启动核心调页线程kswapd（为了防止kswapd启动时将版本信息输出到其他信息中间，核心线调用kswapd_setup()设置kswapd运行所要求的环境，然后再创建
kswapd核心线程）
-
创建事件管理核心线程（start_context_thread()函数启动context_thread()过程，并重命名为keventd）
-
设备初始化（包括并口parport_init()、字符设备chr_dev_init()、块设备
blk_dev_init()、SCSI设备scsi_dev_init()、网络设备net_dev_init()、磁盘初始化及分区检查等等，device_setup()）
- 执行文件格式设置（binfmt_setup()）
-
启动任何使用__initcall标识的函数（方便核心开发者添加启动函数，do_initcalls()）
- 文件系统初始化（filesystem_setup()）
- 安装root文件系统（mount_root()）
至此do_basic_setup()函数返回init()，在释放启动内存段（free_initmem()）并给内核解锁以后，init()打开
/dev/console设备，重定向stdin、stdout和stderr到控制台，最后，搜索文件系统中的init程序（或者由init=命令行参
数指定的程序），并使用 execve()系统调用加载执行init程序。
init()函数到此结束，内核的引导部分也到此结束了，这个由start_kernel()创建的第一个线程已经成为一个用户模式下的进程了。此时系统中存在着六个运行实体：
-
start_kernel()本身所在的执行体，这其实是一个"手工"创建的线程，它在创建了init()线程以后就进入cpu_idle()循环了，它不会在进程（线程）列表中出现
-
init线程，由start_kernel()创建，当前处于用户态，加载了init程序
- kflushd核心线程，由init线程创建，在核心态运行bdflush()函数
- kupdate核心线程，由init线程创建，在核心态运行kupdate()函数
- kswapd核心线程，由init线程创建，在核心态运行kswapd()函数
-
keventd核心线程，由init线程创建，在核心态运行context_thread()函数
对于I386平台
基本相同。
对于2.4.x版内核
这一部分的启动过程在2.4.x内核中简化了不少，缺省的独立初始化过程只剩下网络
（sock_init()）和创建事件管理核心线程，而其他所需要的初始化都使用__initcall()宏
包含在do_initcalls()函数中启动执行。
init进程和inittab引导指令
init进程是系统所有进程的起点，内核在完成核内引导以后，即在本线程（进程）空
间内加载init程序，它的进程号是1。
init程序需要读取/etc/inittab文件作为其行为指针，inittab是以行为单位的描述性（非执行性）文本，每一个指令行都具有以下格式：
id:runlevel:action:process其中id为入口标识符，runlevel为运行级别，action为动作代号，process为具体的执行程序。
id一般要求4个字符以内，对于getty或其他login程序项，要求id与tty的编号相同，否则getty程序将不能正常工作。
runlevel是init所处于的运行级别的标识，一般使用0－6以及S或s。0、1、6运行级别被系统保留，0作为shutdown动作，1作为重启
至单用户模式，6为重启；S和s意义相同，表示单用户模式，且无需inittab文件，因此也不在inittab中出现，实际上，进入单用户模式时，
init直接在控制台（/dev/console）上运行/sbin/sulogin。
在一般的系统实现中，都使用了2、3、4、5几个级别，在Redhat系统中，2表示无NFS支持的多用户模式，3表示完全多用户模式（也是最常用的级
别），4保留给用户自定义，5表示XDM图形登录方式。7－9级别也是可以使用的，传统的Unix系统没有定义这几个级别。runlevel可以是并列的
多个值，以匹配多个运行级别，对大多数action来说，仅当runlevel与当前运行级别匹配成功才会执行。
initdefault是一个特殊的action值，用于标识缺省的启动级别；当init由核心激活
以后，它将读取inittab中的initdefault项，取得其中的runlevel，并作为当前的运行级
别。如果没有inittab文件，或者其中没有initdefault项，init将在控制台上请求输入
runlevel。
sysinit、boot、bootwait等action将在系统启动时无条件运行，而忽略其中的runlevel，其余的action（不含initdefault）都与某个runlevel相关。各个action的定义在inittab的man手册中有详细的描述。
在Redhat系统中，一般情况下inittab都会有如下几项：
id:3:initdefault:
#表示当前缺省运行级别为3--完全多任务模式；
si::sysinit:/etc/rc.d/rc.sysinit
#启动时自动执行/etc/rc.d/rc.sysinit脚本
l3:3:wait:/etc/rc.d/rc 3
#当运行级别为3时，以3为参数运行/etc/rc.d/rc脚本，init将等待其返回
0:12345:respawn:/sbin/mingetty tty0
#在1－5各个级别上以tty0为参数执行/sbin/mingetty程序，打开tty0终端用于
#用户登录，如果进程退出则再次运行mingetty程序
x:5:respawn:/usr/bin/X11/xdm -nodaemon
#在5级别上运行xdm程序，提供xdm图形方式登录界面，并在退出时重新执行
|
rc启动脚本
上一节已经提到init进程将启动运行rc脚本，这一节将介绍rc脚本具体的工作。
一般情况下，rc启动脚本都位于/etc/rc.d目录下，rc.sysinit中最常见的动作就是激活交换分区，检查磁盘，加载硬件模块，这些动作无论
哪个运行级别都是需要优先执行的。仅当rc.sysinit执行完以后init才会执行其他的boot或bootwait动作。
如果没有其他boot、bootwait动作，在运行级别3下，/etc/rc.d/rc将会得到执行，命令行参数为3，即执行
/etc/rc.d/rc3.d/目录下的所有文件。rc3.d下的文件都是指向/etc/rc.d/init.d/目录下各个Shell脚本的符号连
接，而这些脚本一般能接受start、stop、restart、status等参数。rc脚本以start参数启动所有以S开头的脚本，在此之前，如果
相应的脚本也存在K打头的链接，而且已经处于运行态了（以/var/lock/subsys/下的文件作为标志），则将首先启动K开头的脚本，以stop
作为参数停止这些已经启动了的服务，然后再重新运行。显然，这样做的直接目的就是当init改变运行级别时，所有相关的服务都将重启，即使是同一个级别。
rc程序执行完毕后，系统环境已经设置好了，下面就该用户登录系统了。
getty和login
在rc返回后，init将得到控制，并启动mingetty（见第五节）。mingetty是getty的简化，不能处理串口操作。getty的功能一般包括：
- 打开终端线，并设置模式
- 输出登录界面及提示，接受用户名的输入
- 以该用户名作为login的参数，加载login程序
注：用于远程登录的提示信息位于/etc/issue.net中。
login程序在getty的同一个进程空间中运行，接受getty传来的用户名参数作为登录
的用户名。
如果用户名不是root，且存在/etc/nologin文件，login将输出nologin文件的内容，
然后退出。这通常用来系统维护时防止非root用户登录。
只有/etc/securetty中登记了的终端才允许root用户登录，如果不存在这个文件，
则root可以在任何终端上登录。/etc/usertty文件用于对用户作出附加访问限制，如果
不存在这个文件，则没有其他限制。
当用户登录通过了这些检查后，login将搜索/etc/passwd文件（必要时搜索
/etc/shadow文件）用于匹配密码、设置主目录和加载shell。如果没有指定主目录，将
默认为根目录；如果没有指定shell，将默认为/bin/sh。在将控制转交给shell以前，
getty将输出/var/log/lastlog中记录的上次登录系统的信息，然后检查用户是否有新
邮件（/usr/spool/mail/{username}）。在设置好shell的uid、gid，以及TERM，PATH
等环境变量以后，进程加载shell，login的任务也就完成了。
bash
运行级别3下的用户login以后，将启动一个用户指定的shell，以下以/bin/bash为例继续我们的启动过程。
bash是Bourne
Shell的GNU扩展，除了继承了sh的所有特点以外，还增加了很多特
性和功能。由login启动的bash是作为一个登录shell启动的，它继承了getty设置的TERM、PATH等环境变量，其中PATH对于普通用户为"/bin:/usr/bin:/usr/local/bin"，对于root
为"/sbin:/bin:/usr/sbin:/usr/bin"。作为登录shell，它将首先寻找/etc/profile
脚本文件，并执行它；然后如果存在~/.bash_profile，则执行它，否则执行
~/.bash_login，如果该文件也不存在，则执行~/.profile文件。然后bash将作为一个
交互式shell执行~/.bashrc文件（如果存在的话），很多系统中，~/.bashrc都将启动
/etc/bashrc作为系统范围内的配置文件。
当显示出命令行提示符的时候，整个启动过程就结束了。此时的系统，运行着内核，
运行着几个核心线程，运行着init进程，运行着一批由rc启动脚本激活的守护进程（如
inetd等），运行着一个bash作为用户的命令解释器。
tart_kernel ，是用来启动内核的主函数，我想大家都知道这个函数啦，而在该函数的最后将调用一个函数叫 rest_init() ，它执行完，内核就起来了，
asmlinkage void __init start_kernel(void)
{
......
/* Do the rest non-__init'ed, we're now alive */
rest_init();
}
现在我们来看一下 rest_init() 函数，它也在文件 init/main.c 中，它的前面几行是：
static void noinline __init_refok rest_init(void) __releases(kernel_lock)
{
int pid;
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
其中函数 kernel_thread 定义在文件 arch/ia64/kernel/process.c
中，用来启动一个内核线程，这里的 kernel_init 是要执行的函数的指针， NULL 表示传递给该函数的参数为空， CLONE_FS |
CLONE_SIGHAND 为 do_fork 产生线程时的标志，表示进程间的 fs 信息共享，信号处理和块信号共享，然后我就屁颠屁颠地追随到
kernel_init 函数了，现在来瞧瞧它都做了什么好事，它的完整代码如下：
static int __init kernel_init(void * unused)
{
lock_kernel();
/*
* init can run on any cpu.
*/
set_cpus_allowed_ptr(current, CPU_MASK_ALL_PTR);
/*
* Tell the world that we're going to be the grim
* reaper of innocent orphaned children.
* We don't want people to have to make incorrect
* assumptions about where in the task array this
* can be found.
*/
init_pid_ns.child_reaper = current;
cad_pid = task_pid(current);
smp_prepare_cpus(setup_max_cpus);
do_pre_smp_initcalls();
smp_init();
sched_init_smp();
cpuset_init_smp();
do_basic_setup();
/*
* check if there is an early userspace init. If yes, let it do all
* the work
*/
if (!ramdisk_execute_command)
ramdisk_execute_command = "/init";
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
ramdisk_execute_command = NULL;
prepare_namespace();
}
/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
* initmem segments and start the user-mode stuff..
*/
init_post();
return 0;
}
在 kernel_init 函数的一开始就调用了 lock_kernel() 函数，当编译时选上了
CONFIG_LOCK_KERNEL ，就加上大内核锁，否则啥也不做，紧接着就调用了函数 set_cpus_allowed_ptr
，由于这些函数对 init 进程的调起还是有影响的，我们还是一个一个来瞧瞧吧，不要忘了啥东东最好，
static inline int set_cpus_allowed_ptr(struct task_struct *p,
const cpumask_t *new_mask)
{
if (!cpu_isset(0, *new_mask))
return -EINVAL;
return 0;
}
这函数其实就调用了 cpu_isset 宏，定义在文件 "include/linux/cpumask.h 中，如下：
#define cpu_isset(cpu, cpumask) test_bit((cpu), (cpumask).bits)
再来看看 set_cpus_allowed_ptr 的第二个参数类型吧，也定义在文件 include/linux/cpumask.h 中，具体如下：
typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
接着尾随着 DECLAR_BITMAP 宏到文件 include/linux/types.h 中，定义如下：
#define DECLARE_BITMAP(name,bits) /
unsigned long name[BITS_TO_LONGS(bits)]
而宏 BITS_TO_LONGS 定义在文件 include/linux/bitops.h 中，实现如下：
#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
DIV_ROUND_UP 宏定义在文件 include/linux/kernel.h 中， BITS_PER_BYTE 宏定义在文件 include/linux/bitops.h 中，实现如下：
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
#define BITS_PER_BYTE 8
即当 NR_CPUS 为 1 ～ 32 时， cpumask_t 类型为
struct {
}
然后来看看在 set_cpus_allowed_ptr(current, CPU_MASK_ALL_PTR); 中的 CPU_MASK_ALL_PTR 宏，定义在 include/linux/cpumask.h 中：
#define CPU_MASK_ALL_PTR (&CPU_MASK_ALL)
而 CPU_MASK_ALL 宏也定义在文件 include/linux/cpumask.h 中：
#define CPU_MASK_ALL /
(cpumask_t) { { /
[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD /
} }
NR_CPUS 宏定义在文件 include/linux/threads.h 中，实现如下：
#ifdef CONFIG_SMP
#define NR_CPUS CONFIG_NR_CPUS
#else
#define NR_CPUS 1
#endif
CPU_MASK_LAST_WORD 宏定义在文件 include/linux/cpumask.h 中，实现如下：
#define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
BITMAP_LAST_WORD_MASK(NR_CPUS) 宏定义在文件 include/linux/bitmap.h 中，实现如下：
#define BITMAP_LAST_WORD_MASK(nbits) /
( /
((nbits) % BITS_PER_LONG) ? /
(1UL<<((nbits) % BITS_PER_LONG))-1 : ~0UL /
)
当 NR_CPUS 为 1 时， CPU_MASK_LAST_WORD 为 1
当 NR_CPUS 为 2 时， CPU_MASK_LAST_WORD 为 2
当 NR_CPUS 为 n 时， CPU_MASK_LAST_WORD 为 2 的 n-1 次方
有点晕了，我们现在把参数带入，即 set_cpus_allowed_ptr(current, CPU_MASK_ALL_PTR)
－－ >cpu_isset(0,CPU_MASK_ALL_PTR) －－ >test_bit(0,CPU_MASK_ALL_PTR.bits)
即当 NR_CPUS 为 n 时，就把 usigned long bits[0] 的第 n 位置 1 ，应该就如注释所说的， init 能运行在任何 CPU 上吧。
现在 kernel_init 中的 set_cpus_allowed_ptr(current, CPU_MASK_ALL_PTR);
分析完了，我们接着往下看，首先 init_pid_ns.child_reaper = current; init_pid_ns 定义在
kernel/pid.c 文件中
struct pid_namespace init_pid_ns = {
.kref = {
.refcount = ATOMIC_INIT(2),
},
.pidmap = {
[ 0 ... PIDMAP_ENTRIES-1] = { ATOMIC_INIT(BITS_PER_PAGE), NULL }
},
.last_pid = 0,
.level = 0,
.child_reaper = &init_task,
};
它是一个 pid_namespace 结构的变量，先来看看 pid_namespace 的结构，它定义在文件
include/linux/pid_namespace.h 中，具体定义如下：
struct pid_namespace {
struct kref kref;
struct pidmap pidmap[PIDMAP_ENTRIES];
int last_pid;
struct task_struct *child_reaper;
struct kmem_cache *pid_cachep;
unsigned int level;
struct pid_namespace *parent;
#ifdef CONFIG_PROC_FS
struct vfsmount *proc_mnt;
#endif
};
即把当前进程设为接受其它孤儿进程的进程，然后取得该进程的进程 ID ，如：
cad_pid = task_pid(current);
然后调用 smp_prepare_cpus(setup_max_cpus); 如果编译时没有指定 CONFIG_SMP
，它什么也不做，接着往下看，调用 do_pre_smp_initcalls() 函数，它定义在 init/main.c 文件中，实现如下：
static void __init do_pre_smp_initcalls(void)
{
extern int spawn_ksoftirqd(void);
migration_init();
spawn_ksoftirqd();
if (!nosoftlockup)
spawn_softlockup_task();
}
其中 migration_init() 定义在文件 include/linux/sched.h 中，具体实现如下 :
#ifdef CONFIG_SMP
void migration_init(void);
#else
static inline void migration_init(void)
{
}
#endif
好像什么也没有做，然后是调用 spawn_ksoftirqd() 函数，定义在文件 kernel/softirq.c 中，代码如下：
__init int spawn_ksoftirqd(void)
{
void *cpu = (void *)(long)smp_processor_id();
int err = cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
BUG_ON(err == NOTIFY_BAD);
cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
register_cpu_notifier(&cpu_nfb);
return 0;
}
在该函数中，首先调用 smp_processor_id 函数获得当前 CPU 的 ID 并把它赋值给变量 cpu ，然后把 cpu 连同
&cpu_nfb ， CPU_UP_PREPARE 传递给函数 cpu_callback ，我们先看 cpu_callback
的前几行：
static int __cpuinit cpu_callback(struct notifier_block *nfb,
unsigned long action,
void *hcpu)
{
int hotcpu = (unsigned long)hcpu;
struct task_struct *p;
switch (action) {
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
p = kthread_create(ksoftirqd, hcpu, "ksoftirqd/%d", hotcpu);
if (IS_ERR(p)) {
printk("ksoftirqd for %i failed/n", hotcpu);
return NOTIFY_BAD;
}
kthread_bind(p, hotcpu);
per_cpu(ksoftirqd, hotcpu) = p;
break;
从上述代码可以看出当 action 为 CPU_PREPARE 时，将创建一个内核线程并把它赋值给 p ，该进程所要运行的函数为
ksoftirqd ，传递给该函数的参数为 hcpu ，而紧跟其后的” ksoftirqd/%d”,hotcpu
为该进程的名字参数，这就是我们在终端用命令 ps -ef | grep ksoftirqd
所看到的线程；如果进程创建失败，打印出错信息，否则把创建的线程 p 绑定到当前 CPU 的 ID 上，这就是
kthread_bind(p,hotcpu) 所做的，接下来的几行为：
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
wake_up_process(per_cpu(ksoftirqd, hotcpu));
break;
即在 spawn_ksoftirqd 函数中 cpu_callback(&cpu_nfb, CPU_ONLINE, cpu); 的
action 为 CPU_ONLINE 时，将调用 wake_up_process 函数来唤醒当前 CPU 上的 ksoftirqd
进程。最后调用 register_cpu_notifier(&cpu_nfb) ；其实也没做什么，只是简单的返回 0 。返回到
do_pre_smp_initcalls 函数中，接着往下看：
if (!nosoftlockup)
spawn_softlockup_task();
spawn_softlockup_task() 函数定义在文件 include/linux/sched.h 中，是个空函数。
到现在为止， do_pre_smp_initcalls 分析完了，它主要就是创建进程 ksoftirqd ，把它绑定到当前 CPU
上，然后再把该进程拷贝给每个 CPU ，并唤醒所有 CPU 上的进程 ksoftirqd ，就是当我们执行 ps -ef | grep
ksoftirqd 的时候所看到的：
root 4 2 0 08:30 ? 00:00:03 [ksoftirqd/0]
root 7 2 0 08:30 ? 00:00:02 [ksoftirqd/1]
革命尚未成功，同志仍需努力！接着享受吧，呵呵！
现在到了 kernel_init 函数中的 smp_init(); 了
如果在编译时没有选择 CONFIG_SMP ，若定义 CONFIG_X86_LOCAL_APIC 则去调用 APIC_init_uniprocessor() 函数，否则什么也不做，具体代码定义在文件 init/main.c 中：
#ifndef CONFIG_SMP
#ifdef CONFIG_X86_LOCAL_APIC
static void __init smp_init(void)
{
APIC_init_uniprocessor();
}
#else
#define smp_init() do { } while (0)
#endif
如果在编译时选择了 CONFIG_SMP 呢，那么它的实现就如下喽：
/* Called by boot processor to activate the rest. */
static void __init smp_init(void)
{
unsigned int cpu;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(cpu) {
if (num_online_cpus() >= setup_max_cpus)
break;
if (!cpu_online(cpu))
cpu_up(cpu);
}
/* Any cleanup work */
printk(KERN_INFO "Brought up %ld CPUs/n", (long)num_online_cpus());
smp_cpus_done(setup_max_cpus);
}
来看看这个函数的， for_each_present_cpu(cpu) 宏在文件 include/linux/cpumask.h 中实现：
#define for_each_present_cpu(cpu) for_each_cpu_mask((cpu), cpu_present_map)
而 for_each_cpu_mask(cpu,mask) 宏也在文件 include/linux/cpumask.h 中实现：
#if NR_CPUS > 1
#define for_each_cpu_mask(cpu, mask) /
for ((cpu) = first_cpu(mask); /
(cpu) < NR_CPUS; /
(cpu) = next_cpu((cpu), (mask)))
#else /* NR_CPUS == 1 */
#define for_each_cpu_mask(cpu, mask) /
for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
#endif /* NR_CPUS */
即对于每个 cpu 都要执行大括号里的语句，如果当前 cpu 没激活就把它激活的，该函数然后打印一些 cpu 信息，如当前激活的 cpu 数目。
参见include/linux/init.h和vmlinux.lds
1）
所有标识为__init的函数在链接的时候都放在.init.text这个区段内，
在这个区段中，函数的摆放顺序是和链接的顺序有关的，是不确定的。
2）
所有的__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函数之间必须保证一定的调用顺序的问题。
Uboot完成系统的引导并将Linux内核拷贝到内存之后，bootm -> do_bootm_linux()跳转到kernel的起始位置；
压缩过的kernel入口在arch/arm/boot/compressed/head.S，它将调用函数decompress_kernel()解
压,打印“Uncompressing Linux...”，调用gunzip()，打印"done, booting the kernel."
然后call_kernel,执行解压后的kernel,经linux/arch/arm/kernel/head.S调用start_kernel转入
体系结构无关的通用C代码，在start_kernel()中完成了一系列系统初始化，设备及驱动的注册即在此时完成：
－－－－－－－－－－－－－－－－－－－－－－－－－
asmlinkage void __init start_kernel(void)
{
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];
···········································································
printk(KERN_NOTICE "Kernel command line: %s/n", saved_command_line);
//打印内核命令行
parse_early_param();
parse_args("Booting kernel", command_line, __start___param,
__stop___param - __start___param,
&unknown_bootoption);
//解析由BOOT传递的启动参数
···········································································
/* Do the rest non-__init'ed, we're now alive */
rest_init();
}
start_kernel()中的函数rest_init()将创建第一个核心线程kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND)，调用init()函数：
static int init(void * unused)－－－－－－－－－－－－－－－－－－－
{
·······················
do_basic_setup();
······················
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) { //判断在启动时是否指定了init参数
//如果指定则执行用户init进程，成功将不会返回
run_init_process(execute_command);
printk(KERN_WARNING "Failed to execute %s. Attempting "
"defaults.../n", execute_command);
}
/* 如果没有指定init启动参数，则查找下面的目录init进程,成功将不会返回，否则打印出错信息 */
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel.");
}
继而调用函数do_basic_setup()（此时与体系结构相关的部分已经初始化完了,现在开始初始化设备了）：
/*
* Ok, the machine is now initialized. None of the devices
* have been touched yet, but the CPU subsystem is up and
* running, and memory and process management works.
*
* Now we can finally start doing some real work..
*/
static void __init do_basic_setup(void)－－－－－－－－－－－－－－－－－
{
/* drivers will send hotplug events */
init_workqueues();
usermodehelper_init();
driver_init(); //建立设备模型子系统
#ifdef CONFIG_SYSCTL
sysctl_init();
#endif
/* Networking initialization needs a process context */
sock_init();
do_initcalls(); //系统初始化(包括设备，文件系统，内核模块等)
}
－－－－－－－－－－－－－－－－－－－－－－－－－
/**
* driver_init - initialize driver model.
*
* Call the driver model init functions to initialize their
* subsystems. Called early from init/main.c.
*/
void __init driver_init(void)
{
/* These are the core pieces */
devices_init();
－－－－－－－－－－－－－
int __init devices_init(void)
{
return subsystem_register(&devices_subsys);
}
－－－－－－－－－－－－－－－－－－－－－－－
buses_init();
classes_init();
firmware_init();
/* These are also core pieces, but must come after the
* core core pieces.
*/
platform_bus_init();
system_bus_init();
cpu_dev_init();
memory_dev_init();
attribute_container_init();
}
－－－－－－－－－－－－－－－－－－－－－－－－－－－
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_start = .;
*(.initcall1.init)
*(.initcall2.init)
*(.initcall3.init)
*(.initcall4.init)
*(.initcall5.init)
*(.initcall6.init)
*(.initcall7.init)
__initcall_end = .;
－－－－－－－－－－－－－－－－－－－－－
#ifndef MODULE /* 如果驱动模块静态编译进内核 */
···············································
/* 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)
//此处初始化了设备
/*－－－－eg：arch_initcall(at91sam9261_device_init)－－－
static int __init at91sam9261_device_init(void)
{
at91_add_device_udc();
at91_add_device_dm9000();
armebs3_add_input_buttons();
return
platform_add_devices(at91sam9261_devices,
ARRAY_SIZE(at91sam9261_devices));
}
－－－－－－－－－－－－－－－－－－－－－－－－*/
#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)
/**
* 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);
//静态编译的驱动模块作为device_initcall在内核启动就被do_initcalls
/**
* module_exit() - driver exit entry point
* @x: function to be run when driver is removed
*
* module_exit() will wrap the driver clean-up code
* with cleanup_module() when used with rmmod when
* the driver is a module. If the driver is statically
* compiled into the kernel, module_exit() has no effect.
* There can only be one per module.
*/
#define module_exit(x) __exitcall(x);
#else /* MODULE 如果驱动模块动态加载入内核 */
···············································
/* Each module must use one module_init(), or one no_module_init */
#define module_init(initfn) /
static inline initcall_t __inittest(void) /
{ return initfn; } /
int init_module(void) __attribute__((alias(#initfn)));
//insmod 是通过系统调用sys_init_module(const char *name_user, struct module *mod_user)
//将动态驱动模块载入到内核空间
/* This is only required if you want to be unloadable. */
#define module_exit(exitfn) /
static inline exitcall_t __exittest(void) /
{ return exitfn; } /
void cleanup_module(void) __attribute__((alias(#exitfn)));
