uClinux系统对于内存的访问是直接的，（它对******的访问不需要经过MMU，而是直接送到******线上输出），所有程序中访问的******都是实际的物理******。操作系统对内存空间没有保护（这实际上是很多嵌入式系统的特点），各个进程实际上共享一个运行空间（没有独立的******转换表）。

　　一个进程在执行前，系统必须为进程分配足够的连续******空间，然后全部载入主存储器的连续空间中。与之相对应的是标准Linux系统在分配内存时没有必要保证实际物理存储空间是连续的，而只要保证虚存******空间连续就可以了。另外一个方面程序加载******与预期（ld文件中指出的）通常都不相同，这样relocation过程就是必须的。此外磁盘交换空间也是无法使用的，系统执行时如果缺少内存将无法通过磁盘交换来得到改善。

　　uClinux对内存的管理减少同时就给开发人员提出了更高的要求。如果从易用性这一点来说，uClinux的内存管理是一种倒退，退回了到了UNIX早期或是Dos系统时代。开发人员不得不参与系统的内存管理。从编译内核开始，开发人员必须告诉系统这块开发板到底拥有多少的内存（假如你欺骗了系统，那将在后面运行程序时受到惩罚），从而系统将在启动的初始化阶段对内存进行分页，并且标记已使用的和未使用的内存。系统将在运行应用时使用这些分页内存。

　　由于应用程序加载时必须分配连续的******空间，而针对不同硬件平台的可一次成块（连续******）分配内存大小限制是不同（目前针对ez328处理器的uClinux是128k，而针对coldfire处理器的系统内存则无此限制），所以开发人员在开发应用程序时必须考虑内存的分配情况并关注应用程序需要运行空间的大小。另外由于采用实存储器管理策略，用户程序同内核以及其它用户程序在一个******空间，程序开发时要保证不侵犯其它程序的******空间，以使得程序不至于破坏系统的正常工作，或导致其它程序的运行异常。

　　从内存的访问角度来看，开发人员的权利增大了（开发人员在编程时可以访问任意的******空间），但与此同时系统的安全性也大为下降。此外，系统对多进程的管理将有很大的变化，这一点将在uClinux的多进程管理中说明。

　　虽然uClinux的内存管理与标准Linux系统相比功能相差很多，但应该说这是嵌入式设备的选择。在嵌入式设备中，由于成本等敏感因素的影响，普偏的采用不带有MMU的处理器，这决定了系统没有足够的硬件支持实现虚拟存储管理技术。从嵌入式设备实现的功能来看，嵌入式设备通常在某一特定的环境下运行，只要实现特定的功能，其功能相对简单，内存管理的要求完全可以由开发人员考虑。

　　进程：进程是一个运行程序并为其提供执行环境的实体，它包括一个******空间和至少一个控制点，进程在这个******空间上执行单一指令序列。进程******空间包括可以访问或引用的内存单元的集合，进程控制点通过一个一般称为程序计数器（program counter,PC）的硬件寄存器控制和跟踪进程指令序列。

　　fork：由于进程为执行程序的环境，因此在执行程序前必须先建立这个能跑程序的环境。Linux系统提供系统调用拷贝现行进程的内容，以产生新的进程，调用fork的进程称为父进程；而所产生的新进程则称为子进程。子进程会承袭父进程的一切特性，但是它有自己的数据段，也就是说，尽管子进程改变了所属的变量，却不会影响到父进程的变量值。

　　父进程和子进程共享一个程序段，但是各自拥有自己的堆栈、数据段、用户空间以及进程控制块。换言之，两个进程执行的程序代码是一样的，但是各有各的程序计数器与自己的私人数据。

　　当内核收到fork请求时，它会先查核三件事：首先检查存储器是不是足够；其次是进程表是否仍有空缺；最后则是看看用户是否建立了太多的子进程。如果上述说三个条件满足，那么操作系统会给子进程一个进程识别码，并且设定cpu时间，接着设定与父进程共享的段，同时将父进程的inode拷贝一份给子进程运用，最终子进程会返回数值0以表示它是子进程，至于父进程，它可能等待子进程的执行结束，或与子进程各做个的。