uCLinux針對控制領域的嵌入式linux操作系統，它從Linux 2.0/2.4內核派生而來，沿襲了主流Linux的絕大部分特性。適合不具備內存管理單元（MMU）的微處理器/微控制器。沒有MMU支持是uClinux與主流Linux的基本差異。 標準Linux是針對有MMU的處理器設計的。在種處理器上，虛擬地址被送到MMU，把虛擬地址映射為物理地址。通過賦予每個任務不同的虛擬－物理地址轉換映射，支持不同任務之間的保護。 對uCLinux 來說，其設計針對沒有MMU的處理器，不能使用處理器的虛擬內存管理技術。uCLinux仍然采用存儲器的分頁管理，系統在啟動時把實際存儲器進行分頁。在加載應用程序時程序分頁加載。但是由于沒有MMU管理，所以實際上uCLinux采用實存儲器管理策略。uCLinux系統對于內存的訪問是直接的，所有程序中訪問的地址都是實際的物理地址。操作系統對內存空間沒有保護，各個進程實際上共享一個運行空間。一個進程在執行前，系統必須為進程分配足夠的連續地址空間，然后全部載入主存儲器的連續空間中。 同時，uClinux有著特別小的內核和用戶軟件空間。熟悉主流Linux的開發者會注意到在 uClinux下工作的微小差異，但同樣也可以很快熟悉uclinux的一些特性。對于設計內核或系統空間的應用程序的開發者，要特別注意uClinux 既沒有內存保護，也沒有虛擬內存模型，另外，有些內核系統調用也有差異。 1.1 內存保護 沒有內存保護（Memory Protection）的操作會導致這樣的結果：即使由無特權的進程來調用一個無效指針，也會觸發一個地址錯誤，并潛在地引起程序崩潰，甚至導致系統的掛起。顯然，在這樣的系統上運行的代碼必須仔細編程，并深入測試來確保健壯性和安全。 對于普通的Linux來說，需要運行不同的用戶程序，如果沒有內存保護將大大降低系統的安全性和可＊性；然而對于嵌入式uClinux系統而言，由于所運行的程序往往是在出廠前已經固化的，不存在危害系統安全的程序侵入的隱患，因此只要應用程序經過較完整的測試，出現問題的概率就可以控制在有限的范圍內。 1.2 虛擬內存 沒有虛擬內存（Virtual Memory）主要導致下面幾個后果： 首先，由內核所加載的進程必須能夠獨立運行，與它們在內存中的位置無關。實現這一目標的第一種辦法是一旦程序被加載到RAM中，那么程序的基準地址就“固定”下來；另一種辦法是產生只使用相對尋址的代碼（稱為“位置無關代碼”，Position Independent Code，簡稱PIC）。uClinux對這兩種模式都支持。 其次，要解決在扁平（flat）的內存模型中的內存分配和釋放問題。非常動態的內存分配會造成內存碎片，并可能耗盡系統的資源。對于使用了動態內存分配的那些應用程序來說，增強健壯性的一種辦法是用預分配緩沖區池（Preallocated buffer pool）的辦法來取代malloc（）調用。 由于uclinux中不使用虛擬內存，進出內存的頁面交換也沒有實現，因為不能保證頁面會被加載到RAM中的同樣位置。在普通計算機上，操作系統允許應用程序使用比物理內存（RAM）更大的內存空間，這往往是通過在硬盤上設立交換分區來實現的。但是，在嵌入式系統中，通常都用FLASH存儲器來代替硬盤，很難高效地實現內存頁面交換的存取，因此，對運行的應用程序都限制其可分配空間不大于系統的RAM空間。 最后，uClinux目標板處理器缺乏內存管理的硬件單元，使得Linux的系統接口需要作些改變。有可能最大的不同就是沒有fork（）和brk（）系統調用。調用fork（）將復制出進程來創建一個子進程。在Linux下，fork（）是使用copy-on-write頁面來實現的。由于沒有MMU， uclinux不能完整、可＊地復制一個進程，也沒有對copy-on-write的存取。為了彌補這一缺陷，uClinux實現了vfork（），當父進程調用vfork（）來創建子進程時，兩個進程共享它們的全部內存空間，包括堆棧。子進程要么代替父進程執行（此時父進程已經sleep）直到子進程調用exitI（）退出，要么調用exec（）執行一個新的進程，這個時候將產生可執行文件的加載。即使這個進程只是父進程的拷貝，這個過程也不能避免。當子進程執行exit（）或exec（）后，子進程使用wakeup把父進程喚醒，父進程繼續往下執行。