总结一下Linux内核启动一个ELF可执行文件的大概过程，其中大部分的细节都并没有深究过，但总的流程还算比较清楚。如果涉及到与体系结构有关的内容，只讲ARM的。
就从do_execve()函数开始讲起，因为无论是系统调用（即一个进程启动另一个进程）还是启动kernel线程（即系统自己决定启动一个进程，比如系统引导后由kernel启动的第一个进程init）都会调到这个函数。
do_execve()只是一个封装，接着就直接调用do_execve_common()，这是真正主要的部分。下面只捡主要的步骤说，细节不论。
先是构造一个结构体struct linux_binprm的实例，这个结构里将包含有可执行文件的各种参数。
接下来，调用bprm_mm_init()初始化进程的虚拟内存，其中比较重要的，一个是构造了进程的mm_struct结构，再就是为进程申请了页表。当然这个时候还没有什么内容被映射到进程空间，所以只需要申请PGD就可以了。
[c]
retval = bprm_mm_init(bprm);
if (retval)
goto out_file;
[/c]
不过也有例外，在函数pgd_t *pgd_alloc(struct mm_struct *mm)中(arch/arm/mm/pgd.c)，还会区分“中断向量表”是在低内存还是在高内存。在比较早的ARM系统中，中断向量表只能被存放在靠近内存0地址附近（一页就够了），所以所有的进程都必须注意这一点，并且把这一页给让出来；但是在ARMv4之后，中断向量表的位置就可以配置，可以把中断向量表的位置设置到高内存处（靠近4G边界的地方），这样的话，中断向量表就位于内核空间，在0~3G的进程空间中就不用再特别考虑它了。
下面的这段代码就是做了一个判断，如果中断向量表在低地址处，就在这里先把从0地址开始的这一页给映射起来，并把它给占上。
[c]
pgd_t *pgd_alloc(struct mm_struct *mm)
{
......
if (!vectors_high()) {
new_pud = pud_alloc(mm, new_pgd, 0);
if (!new_pud)
goto no_pud;
new_pmd = pmd_alloc(mm, new_pud, 0);
if (!new_pmd)
goto no_pmd;
......
}
[/c]
接着，调用prepare_binprm()，它会拷贝可执行文件最开始处的128个字节，用于识别文件格式。
[c]
retval = prepare_binprm(bprm);
if (retval < 0)
goto out;
[/c]
下面会做三次从当前进程空间到内核空间的字符串复制，这些信息分别是文件名、环境变量和参数。因为这些字符信息现在还在当前的用户进程空间中，现在先把它们复制到bprm中去，等到新的进程空间准备好了，再把它们复制到新进程中去（这是在load_elf_binary()->create_elf_table()中完成的）。
[c]
retval = copy_strings_kernel(1, &bprm->filename, bprm);
if (retval < 0)
goto out;
bprm->exec = bprm->p;
retval = copy_strings(bprm->envc, envp, bprm);
if (retval < 0)
goto out;
retval = copy_strings(bprm->argc, argv, bprm);
if (retval < 0)
goto out;
[/c]
在这之后就调用search_binary_handler()，在其中根据前面读到的文件头信息来识别可执行文件格式。
[c]
retval = search_binary_handler(bprm,regs);
if (retval < 0)
goto out;
[/c]
系统支持的每一种文件格式，都会有一个linux_binfmt结构的注册项。内核找到相应的注册项，并调用load_binary回调函数。对于ELF文件来说，load_elf_binary()就会被查找到并调用。
[c]
struct linux_binfmt {
struct list_head lh;
struct module *module;
int (*load_binary)(struct linux_binprm *, struct pt_regs * regs);
int (*load_shlib)(struct file *);
int (*core_dump)(struct coredump_params *cprm);
unsigned long min_coredump;
};
[/c]
load_elf_binary()的工作已经在前一篇中提到过，它解析了ELF文件，并映射了各区域的VMA，构造了进程的虚拟内存空间。在这个函数的最后，调用了一个与体系结构相关的宏：(arch/arm/include/asm/processor.h)
[c]
#define start_thread(regs,pc,sp) \
({ \
unsigned long *stack = (unsigned long *)sp; \
set_fs(USER_DS); \
memset(regs->uregs, 0, sizeof(regs->uregs)); \
if (current->personality & ADDR_LIMIT_32BIT) \
regs->ARM_cpsr = USR_MODE; \
else \
regs->ARM_cpsr = USR26_MODE; \
if (elf_hwcap & HWCAP_THUMB && pc & 1) \
regs->ARM_cpsr |= PSR_T_BIT; \
regs->ARM_cpsr |= PSR_ENDSTATE; \
regs->ARM_pc = pc & ~1; \
regs->ARM_sp = sp; \
regs->ARM_r2 = stack[2]; \
regs->ARM_r1 = stack[1]; \
regs->ARM_r0 = stack[0]; \
nommu_start_thread(regs); \
})
[/c]
它的作用很重要，是设置寄存器，可以看到，这里已经把十分关键的cpsr、pc以及sp都设置好，进程基本上已经就绪了，随时可以投入CPU运行。那么准备好的进程究竟什么时候被装入CPU呢？只需要跟踪参数regs就能够找到答案。
struct pt_regs结构的参数regs是从do_execve()开始就一直带下来的，在此之前它又从哪来呢？再往上一级，看看系统调用sys_execve()，在这里regs仍然是传入的参数。我还不太清楚系统调用的发生过程，但是可以猜测，这个regs应该是中断发生时用户进程的寄存器信息。
现在，当新的进程已经准备就绪，再回到sys_execve()中时，regs里面已经是新进程的寄存器信息了，如果再往上，中断将结束返回，CPU重新回到用户模式，而这时寄存器中正是新进程的数据，pc正指向ELF文件中elf_entry所指向的代码，于是在下一指令周期，一个全新的进程就启动了。