exec系统调用：该系统调用提供一个进程去执行另一个进程的能力，exec系统调用是??序的堆栈数据段程序段都会被修改，只有用户区维持不变。

　　vfork系统调用：由于在使用fork时，内核会将父进程拷贝一份给子进程，但是这样的做法相当浪费时间，因为大多数的情形都是程序在调用fork后就立即调用exec，这样刚拷贝来的进程区域又立即被新的数据覆盖掉。因此Linux系统提供一个系统调用vfork，vfork假定系统在调用完成vfork后会马上执行exec，因此vfork不拷贝父进程的页面，只是初始化私有的数据结构与准备足够的分页表。这样实际在vfork调用完成后父子进程事实上共享同一块存储器（在子进程调用exec或是exit之前），因此子进程可以更改父进程的数据及堆栈信息，因此vfork系统调用完成后，父进程进入睡眠，直到子进程执行exec。当子进程执行exec时，由于exec要使用被执行程序的数据，代码覆盖子进程的存储区域，这样将产生写保护错误（do_wp_page）（这个时候子进程写的实际上是父进程的存储区域），

　　这个错误导致内核为子进程重新分配存储空间。当子进程正确开始执行后，将唤醒父进程，使得父进程继续往后执行。

　　uClinux没有mmu管理存储器，在实现多个进程时（fork调用生成子进程）需要实现数据保护。

　　uClinux的fork和vfork：uClinux的fork等于vfork。实际上uClinux的多进程管理通过vfork来实现。这意味着uClinux系统fork调用完程后，要么子进程代替父进程执行（此时父进程已经sleep）直到子进程调用exit退出，要么调用exec执行一个新的进程，这个时候将产生可执行文件的加载，即使这个进程只是父进程的拷贝，这个过程也不能避免。当子进程执行exit或exec后，子进程使用wakeup把父进程唤醒，父进程继续往下执行。

　　uClinux的这种多进程实现机制同它的内存管理紧密相关。uClinux针对nommu处理器开发，所以被迫使用一种flat方式的内存管理模式，启动新的应用程序时系统必须为应用程序分配存储空间，并立即把应用程序加载到内存。缺少了MMU的内存重映射机制，uClinux必须在可执行文件加载阶段对可执行文件reloc处理，使得程序执行时能够直接使用物理内存。

　　uClinux是专门针对没有MMU的处理器而设计的，即uClinux无法使用处理器的虚拟内存管理技术。实际上uClinux采用实存储器管理策略，通过******总线对物理内存进行直接访问。所有程序中访问的******都是实际的物理******，所有的进程都在一个运行空间中运行（包括内核进程），这样的运行机制给程序员带来了不小的挑战，在操作系统不提供保护的情况下必需小心设计程序和数据空间，以免引起应用程序进程甚至是内核的崩溃。

　　uClinux仍然采用存储器的分页管理，系统在启动时把实际存储器进行分页，在加载应用程序时程序分页加载。一个进程在执行前，系统必须为进程分配足够的连续******空间，然后全部载入主存储器的连续空间中。系统不含MMU带来的另外一个问题是磁盘交换空间无法使用，对于资源有限的嵌入式系统而言，系统执行时如果缺少内存将无法通过磁盘交换来得到改善。

　　MMU的省略虽然带来了系统及应用程序开发的限制，但对于成本和体积敏感的嵌入式设备而言，其应用环境和应用需求并不要求复杂和相对昂贵的硬件体系,对于功能简单的专用嵌入式设备，内存的分配和管理完全可以由开发人员考虑。

　　由于uClinux没有MMU管理存储器，在实现多个进程时需要实现数据保护。uClinux的虽然支持fork函数，但其实质是和vfork：实际上uClinux所有的多进程管理都通过vfork来实现。

　　vfork不拷贝父进程的页面，只是初始化私有的数据结构与准备足够的分页表。调用完成后父子进程事实上共享同一块存储器，因此子进程可以更改父进程的数据及堆栈信息，所有父进程进入睡眠，直到子进程执行exec。当子进程正确开始执行后，将唤醒父进程，使得父进程继续往后执行。这意味着uClinux系统fork调用完成后，要么子进程代替父进程执行（此时父进程已经休眠）直到子进程调用exit退出，要么调用exec执行一个新的进程。