uCLinux嵌入式系统开发环境建立

　　4、 应用程序设计

　　我们知道，在主流的Linux平台上，已经有了非常丰富的、开源应用程序，使得开发者很容易获得前人的成果作为参考 ，编写更适合自己的程序。然而，对于很多已经在标准Linux环境中工作得很好的程序，并不能直接在uClinux环境上运行。一方面是由于嵌入式的uCLinux所使用的处理器和普通PC不同，指令集、CPU结构上的差导致uClinux上运行和的程序需要专门为该类型处理器交叉编译产生：另一方面uCLinux是为了没有内存管理单元(MMU)的处理器、控制器设计，并做了较大幅度的精简，所以，在标准Linux上可以作用的一些函数和系统调用在uCLinux上有可能就行不通了。

　　标准Linux是针对有MMU的处理器设计的。在这种处理器上，虚拟地址被送到MMU，把虚拟地址映射为物理地址。通过赋予每个任务不同的虚拟一物理地址转换映射，支持不同任务之间的保护。

　　对uCLinux来说，其设计针对没有MMU的处理器，不能使用处理器的虚拟内存管理技术。uCLinux仍然采用存储器的分页管理。系统在启动时把实际存储器进行分页。在加载应用程序时程序分页加载。但是由于没有MMU管理，所以实际上uCLinux采用实存储器管理策略。uCLinux系统对于内存的访问是直接的。所有程序中访问的地址都是实际的物理地址。操作系统对成倍存空间没有保护，各个进程实际上共享一个运行空间。一个进程在执行前。系统必须为进程分配足够的连续地址空间。然后全部载入主存储器的连续空间中。

　　同时，uClinux有着特别小的内核和用户软件空间。熟悉主流Linux的开发者会注意到在uClinx下工作的微小差异，但同样也可以很快熟悉uClinux的一些特性。对于设计内核或系统空间的应用程序的开发者，要特点注意uClinux既没有内存保护，也没有虚拟内存模型，另外，有些内核系统调用也有差异。

　　没有内存保护(Memory Protection)的操作会导致这样的结果：即使由无特权的进程来调用一个无效指针，也会触发一个地址错误，并潜在引起程序崩溃，甚至导致系统的挂起。显然，在这样的系统上运行的代码必须仔细编程，并深入测试来确保健壮性和安全。

　　对于普通的Linux来说，需要运行不同的用户程序，如果没有内存保护将大大降低系统的安全性和可靠性：然后对嵌入式uClinux系统而言，由于所运行的程序往往是在出厂前已经固化的，不存在危害系统安全的程序侵入的隐患，因此只要应用程序经过较完整的测试，出现问题的概率就可以控制在有限的范围内。没有虚拟内存(Virtual Memory)主要导致下面几个后果： 首先，由内核所加载的进程必须能够独立运行，与它们在内存中的位置无关。实现这一目标的第一种办法是一旦程序被加载到RAM中，那么程序的基准地址就“固定”下来：另一种办法是产生只使用相对寻址的代码(称为“位置无关代码”，Position Independent Code，简称PIC)。uClinux 对这两种模式都支持。

　　其次，要解决在扁平(flat)的内存模型中的内存分配和问题。非常动态的内存分配会造成内存碎片，并可能耗尽系统的资源。对于使用了动态的内存分配的那些应用程序来说，增强健壮性的一种办法是用预分配缓冲区池(Prelllocated buffer pool)的办法来取代malloc()调用。由于uClinux中不使用虚拟内存，进出内存的页面交换也没有实现，，因为不能保证页面会被加载到RAM中的同样位置。要普通计算机上，操作系统允许应用程序使用比物理内存(RAM)更大的内存空间，这往往是通过在硬盘上设立交换分区来实现的。但是，在嵌入式系统中，通常都用FLASH存储器来代替硬盘，很难高效地实现内存页面交换的存取，因此，对运行的应用程序都限制其可分配空间不大于系统的RAM空间。最后，uClinux目标处理器缺乏内存管理的硬件单元，使得Linux的系统接口需要作些改变，有可能最大的不同就是没有fork()和brk()系统调用。调用fork()将复制出进程来创建一个子进程。在Linux下，fork()是使用copy-on-write页面来实现的。由于没有MMU，uClinux不能完整、可靠村地复制一个进程。也没有对copy-on-write的存取。为了弥补这一缺陷，uClinux实现了发vfok(),当父进程调用vfork()来创建子进程时，两个进程共享它们的全部内存空间，包括堆栈。 子进程要么代替父进程执行(此时父进程已经sleep)直到子进程调 用exitI()退出，要么调用eexec()执行一个新的进程，这个时候将产生可执行文件的加载。即使这个进程只是父进程的拷贝，这个过程也不能避免。当子进程执行exit()或exec()后，子进程使用wakeup把父进程唤醒，父进程继续往下执行。注意，多任务并没有受影响。哪些旧式的、广泛使用fork()的网络后台程序(daemon)的确是需要修改的。由于子进程运行在和父进程同亲的地址空间内，在一些情况下，也需要修改两个进程的行为。很多现代的程序依赖子进程业执行基本任务，使得即时进程负载很重时，系统仍可以保持一种“可交互”的状态，这些程序可能需要实质上的修改来在uClinux下完成同样的任务。如果一个关键的应用程序非常依赖这样的结构，那就不得不对它重新编写了。

　　假设有一个简单的网络后台程序(daemon),大量使用了fork()。这个daemon总监听一个知名端口或套接字)等待网络客户端来连接。当客户端连接时。这个daemon给它一个新的连接信息(新的socket编号)，并调用fork()。子进程接下来就会和客户端在新的socket上进行连接。而父进程被释放，可以继续监听新的连接。

　　uClinux既没有自动生长的堆栈，也没有brk()函数，这样，用户空间的程序必须使用mmap()命令来分配内存。为了方便，在uClinux的C语言库中所实现的malloc()实质上就是一个mmap().在编译时，可以指定程序的堆栈大小。其实，除了一些设计内存和系统调用的程序之外，在x86版本的gcc编译器下编译通过的软件通常不需要做大的改动就可以用交叉编译到uClinux上运行。如编译heelo. xxx-elf-gcc-Wall ?elf2flt-mxxx hello.c-lc-0hello.out

　　参数“-Wall”指定产生全部的警告;-elf2flt指定自动调用elf转换flat格式的工具; -mxxx指定了处理器的指令集;-lc指定了链接信息(ld);-o指定输出文件的名字。编译成功后得到的hello.out就可以在uClinux环境上运行。

　　需要注意的，uClinux采用的是精简了的c程序库uClibc,uClibc提供大多数的类UNIX的C程序调用。如果应用程序需要用到uClibc中没有提供的函数，这些函数可以加到uClibc中、或者作为一个独立的库、或者加到应用程序上面来进链接。

　　uCLinux 对用户程序采用静态链接的形式，这种做法会使应用程序变大，但是基于内存管理的问题也就是基于没有MMU的特性，只能这样做，同时这种做法也更接近于通常嵌入式系统的做法。

　　5.结论

　　本方讨论了嵌入式linux-Uclinux的特点和Uclinux 开发环境的建立。并结合我的工作着重阐述了如何开发基于Uclinux的应用程序 ，这些技术几乎都跟具体设备无关，可以就用于任何硬件设备，具有相当的通用性。