uClinux和Linux的具體異同

　　uCLinux是針對控制領(lǐng)域的嵌入式linux操作系統，它從Linux 2.0/2.4內核派生而來(lái)，沿襲了主流Linux的絕大部分特性。適合不具備內存管理單元(MMU)的微處理器/微控制器。沒(méi)有MMU支持是uClinux與主流Linux的基本差異。

　　標準Linux是針對有MMU的處理器設計的。在這種處理器上，虛擬地址被送到MMU，把虛擬地址映射為物理地址。通過(guò)賦予每個(gè)任務(wù)不同的虛擬－物理地址轉換映射，支持不同任務(wù)之間的保護。

　　對uCLinux 來(lái)說(shuō)，其設計針對沒(méi)有MMU的處理器，不能使用處理器的虛擬內存管理技術(shù)。uCLinux仍然采用存儲器的分頁(yè)管理，系統在啟動(dòng)時(shí)把實(shí)際存儲器進(jìn)行分頁(yè)。在加載應用程序時(shí)程序分頁(yè)加載。但是由于沒(méi)有MMU管理，所以實(shí)際上uCLinux采用實(shí)存儲器管理策略。uCLinux系統對于內存的訪(fǎng)問(wèn)是直接的，所有程序中訪(fǎng)問(wèn)的地址都是實(shí)際的物理地址。操作系統對內存空間沒(méi)有保護，各個(gè)進(jìn)程實(shí)際上共享一個(gè)運行空間。一個(gè)進(jìn)程在執行前，系統必須為進(jìn)程分配足夠的連續地址空間，然后全部載入主存儲器的連續空間中。

　　同時(shí)，uClinux有著(zhù)特別小的內核和用戶(hù)軟件空間。熟悉主流Linux的開(kāi)發(fā)者會(huì )注意到在 uClinux下工作的微小差異，但同樣也可以很快熟悉uclinux的一些特性。對于設計內核或系統空間的應用程序的開(kāi)發(fā)者，要特別注意uClinux 既沒(méi)有內存保護，也沒(méi)有虛擬內存模型，另外，有些內核系統調用也有差異。

　　1.1 內存保護

　　沒(méi)有內存保護(Memory Protection)的操作會(huì )導致這樣的結果：即使由無(wú)特權的進(jìn)程來(lái)調用一個(gè)無(wú)效指針，也會(huì )觸發(fā)一個(gè)地址錯誤，并潛在地引起程序崩潰，甚至導致系統的掛起。顯然，在這樣的系統上運行的代碼必須仔細編程，并深入測試來(lái)確保健壯性和安全。

　　對于普通的Linux來(lái)說(shuō)，需要運行不同的用戶(hù)程序，如果沒(méi)有內存保護將大大降低系統的安全性和可*性；然而對于嵌入式uClinux系統而言，由于所運行的程序往往是在出廠(chǎng)前已經(jīng)固化的，不存在危害系統安全的程序侵入的隱患，因此只要應用程序經(jīng)過(guò)較完整的測試，出現問(wèn)題的概率就可以控制在有限的范圍內。

　　1.2 虛擬內存

　　沒(méi)有虛擬內存(Virtual Memory)主要導致下面幾個(gè)后果：

　　首先，由內核所加載的進(jìn)程必須能夠獨立運行，與它們在內存中的位置無(wú)關(guān)。實(shí)現這一目標的第一種辦法是一旦程序被加載到RAM中，那么程序的基準地址就“固定”下來(lái)；另一種辦法是產(chǎn)生只使用相對尋址的代碼（稱(chēng)為“位置無(wú)關(guān)代碼”，Position Independent Code，簡(jiǎn)稱(chēng)PIC）。uClinux對這兩種模式都支持。

　　其次，要解決在扁平(flat)的內存模型中的內存分配和釋放問(wèn)題。非常動(dòng)態(tài)的內存分配會(huì )造成內存碎片，并可能耗盡系統的資源。對于使用了動(dòng)態(tài)內存分配的那些應用程序來(lái)說(shuō)，增強健壯性的一種辦法是用預分配緩沖區池(Preallocated buffer pool)的辦法來(lái)取代malloc()調用。

　　由于uclinux中不使用虛擬內存，進(jìn)出內存的頁(yè)面交換也沒(méi)有實(shí)現，因為不能保證頁(yè)面會(huì )被加載到RAM中的同樣位置。在普通計算機上，操作系統允許應用程序使用比物理內存(RAM)更大的內存空間，這往往是通過(guò)在硬盤(pán)上設立交換分區來(lái)實(shí)現的。但是，在嵌入式系統中，通常都用FLASH存儲器來(lái)代替硬盤(pán)，很難高效地實(shí)現內存頁(yè)面交換的存取，因此，對運行的應用程序都限制其可分配空間不大于系統的RAM空間。

　　最后，uClinux目標板處理器缺乏內存管理的硬件單元，使得Linux的系統接口需要作些改變。有可能最大的不同就是沒(méi)有fork()和brk()系統調用。調用fork()將復制出進(jìn)程來(lái)創(chuàng )建一個(gè)子進(jìn)程。在Linux下，fork()是使用copy-on-write頁(yè)面來(lái)實(shí)現的。由于沒(méi)有MMU， uclinux不能完整、可*地復制一個(gè)進(jìn)程，也沒(méi)有對copy-on-write的存取。為了彌補這一缺陷，uClinux實(shí)現了vfork()，當父進(jìn)程調用vfork()來(lái)創(chuàng )建子進(jìn)程時(shí)，兩個(gè)進(jìn)程共享它們的全部?jì)却婵臻g，包括堆棧。子進(jìn)程要么代替父進(jìn)程執行（此時(shí)父進(jìn)程已經(jīng)sleep）直到子進(jìn)程調用exitI()退出，要么調用exec()執行一個(gè)新的進(jìn)程，這個(gè)時(shí)候將產(chǎn)生可執行文件的加載。即使這個(gè)進(jìn)程只是父進(jìn)程的拷貝，這個(gè)過(guò)程也不能避免。當子進(jìn)程執行exit()或exec()后，子進(jìn)程使用wakeup把父進(jìn)程喚醒，父進(jìn)程繼續往下執行。

　　注意，多任務(wù)并沒(méi)有受影響。哪些舊式的、廣泛使用fork()的網(wǎng)絡(luò )后臺程序（daemon）的確是需要修改的。由于子進(jìn)程運行在和父進(jìn)程同樣的地址空間內，在一些情況下，也需要修改兩個(gè)進(jìn)程的行為。

　　很多現代的程序依賴(lài)子進(jìn)程來(lái)執行基 本任務(wù)，使得即時(shí)在進(jìn)程負載很重時(shí)，系統仍可以保持一種“可交互”的狀態(tài)，這些程序可能需要實(shí)質(zhì)上的修改來(lái)在uCLinux下完成同樣的任務(wù)。如果一個(gè)關(guān)鍵的應用程序非常依賴(lài)這樣的結構，那就不得不對它重新編寫(xiě)了。


　　假設有一個(gè)簡(jiǎn)單的網(wǎng)絡(luò )后臺程序(daemon)，大量使用了fork()。這個(gè)daemon總監聽(tīng)一個(gè)知名端口（或套接字）等待網(wǎng)絡(luò )客戶(hù)端來(lái)連接。當客戶(hù)端連接時(shí)，這個(gè)daemon給它一個(gè)新的連接信息（新的socket編號），并調用fork()。子進(jìn)程接下來(lái)就會(huì )和客戶(hù)端在新的socket上進(jìn)行連接，而父進(jìn)程被釋放，可以繼續監聽(tīng)新的連接。

　　uClinux 既沒(méi)有自動(dòng)生長(cháng)的堆棧，也沒(méi)有brk()函數，這樣，用戶(hù)空間的程序必須使用mmap() 命令來(lái)分配內存。為了方便，在uclinux的C語(yǔ)言庫中所實(shí)現的malloc()實(shí)質(zhì)上就是一個(gè)mmap()。在編譯時(shí)，可以指定程序的堆棧大小。
linux操作系統文章專(zhuān)題:linux操作系統詳解（linux不再難懂）