說一說uCLinux是什么及uCLinux有什么用

今天來說一下關(guān)于uCLinux是什么及uCLinux有什么用這方面的一些訊息，不少朋友對于uCLinux是什么及uCLinux有什么用這方面的信息頗感興趣的。小編今天就為此整理一些相關(guān)的訊息，希望對有需要的朋友有所幫助。

uCLinux 表示 micro-control linux.即“微控制器領(lǐng)域中的 Linux 系統(tǒng)”，是 Lineo 公司的主打產(chǎn)品，同時也是開放源碼的嵌入式 Linux 的典范之作。uCLinux 主要是針對目標處理器沒有存儲管理單元 MMU(Memory Management Unit)的嵌入式系統(tǒng)而設(shè)計的。它已經(jīng)被成功地移植到了很多平臺上。由于沒有 MMU，其多任務(wù)的實現(xiàn)需要一定技巧。

uclinux

簡介

Linux 是一種很受歡迎的操作系統(tǒng)，它與 UNIX 系統(tǒng)兼容，開放源代碼。它原本被設(shè)計為桌面系統(tǒng)，現(xiàn)在廣泛應(yīng)用于服務(wù)器領(lǐng)域。而更大的影響在于它正逐漸的應(yīng)用于嵌入式設(shè)備。uClinux 正是在這種氛圍下產(chǎn)生的。在 uClinux 這個英文單詞中 u 表示 Micro，小的意思，C 表示 Control，控制的意思，所以 uClinux 就是 Micro-Control-Linux，字面上的理解就是”針對微控制領(lǐng)域而設(shè)計的 Linux 系統(tǒng)”。

uClinux 是嵌入式 Linux 領(lǐng)域非常重要的分支，已成功應(yīng)用于路由器、機頂盒、PDA 等領(lǐng)域，與標準 Linux 在內(nèi)存管理方面有著本質(zhì)的區(qū)別。

uCLinux 是一種優(yōu)秀的嵌入式 Linux 版本，是 micro-Controller-Linux 的縮寫。它秉承了標準 Linux 的優(yōu)良特性， 經(jīng)過各方面的小型化改造，形成了一個高度優(yōu)化的、代碼緊湊的嵌入式 Linux。雖然它的體積很小，卻仍然保留了 Linux 的大多數(shù)的優(yōu)點：穩(wěn)定、良好的移植性、優(yōu)秀的網(wǎng)絡(luò)功能、對各種文件系統(tǒng)完備的支持和標準豐富的 API。它專為嵌入式系統(tǒng)做了許多小型化的工作，目前已支持多款 CPU。 其編譯后目標文件可控制在幾百 KB 數(shù)量級，并已經(jīng)被成功地移植到很多平臺上。

uClinux 從 Linux 2.0/2.4 內(nèi)核派生而來,沿襲了 Linux 的絕大部分特性。它是專門針對沒有 MMU(內(nèi)存管理單元)的 CPU,并且為嵌入式系統(tǒng)做了許多小型化的工作。它通常用于具有很少內(nèi)存或 Flash 的嵌入式操作系統(tǒng)。在 GNU 通用許可證的保證下,運行 uClinux 操作系統(tǒng)的用戶可以使用幾乎所有的 Linux API 函數(shù)。由于經(jīng)過了裁剪和優(yōu)化,它形成了一個高度優(yōu)化,代碼緊湊的嵌入式 Linux。它具有體積小、穩(wěn)定、良好的移植性、優(yōu)秀的網(wǎng)絡(luò)功能、完備的對各種文件系統(tǒng)的支持，以及豐富的 API 函數(shù)等優(yōu)點。uClinux 與 Linux 在兼容性方面表現(xiàn)出色，uClinux 除了不能實現(xiàn) fork()外，其余 uClinux 的 API 函數(shù)與標準 Linux 完全相同。

針對沒有 MMU 的 CPU

全球每年生產(chǎn)的 CPU 的數(shù)量大概在二十億顆左右，其中大部分是應(yīng)用于專用性很強的各類嵌入式系統(tǒng)。大部分嵌入式系統(tǒng)為了減少系統(tǒng)復(fù)雜程度、降低硬件及開發(fā)成本和運行功耗，在硬件設(shè)計中取消了內(nèi)存管理單元(MMU)模塊。最初，運行于這類沒有 MMU 的 CPU 之上的都是一些很簡單的單任務(wù)操作系統(tǒng)，或者更簡單的控制程序，甚至根本就沒有操作系統(tǒng)而直接運行應(yīng)用程序。在這種情況下，系統(tǒng)無法運行復(fù)雜的應(yīng)用程序，或者效率很低，并且所有的應(yīng)用程序需要重新開發(fā)，還要求開發(fā)人員十分了解硬件特性。這些都阻礙了不含 MMU 的嵌入式產(chǎn)品開發(fā)的速度和應(yīng)用水平。

uClinux 專門針對沒有 MMU 的 CPU，并且為嵌入式系統(tǒng)做了許多小型化的工作。uClinux 是一個完全符合 GNU/GPL 公約的項目，完全開放代碼。

最初的 uClinux 僅僅支持 Palm 硬件系統(tǒng)，基于 Linux 2.0 內(nèi)核。隨著系統(tǒng)的日益改進，支持的內(nèi)核版本從 2.0、2.2、2.4 一直到現(xiàn)在最新的 2.6。系統(tǒng)的開發(fā)人員從兩人增加到了目前的 12 人，支持的硬件系統(tǒng)也從一種增加到了目前的十余種(支持的硬件平臺如 Motorola 公司的 M68328、M68EN322、MC68360、DragonBall 系列如 68EZ328、68VZ328，ColdFire 系列的如 5272、5307，ARM 7TDMI、MC68EN302、ETRAX、Intel i960、PRISMA、Atari 68k 等等。)

根據(jù) Linuxdevices 網(wǎng)站 2004 年 3 月的調(diào)查，uClinux 在全球嵌入式 Linux 市場所占的份額已位居第二，僅僅落后于定制 Linux(即自己下載源碼進行修改定制)。同時 Linux 在全球嵌入式操作系統(tǒng)的市場份額依然處于統(tǒng)治地位(占 40%以上),領(lǐng)先第二名微軟公司的嵌入式操作系統(tǒng)三倍以上(市場份額約 13%)。

特點

標準 Linux 可能采用的小型化方法

1. 重新編譯內(nèi)核

Linux 內(nèi)核采用模塊化的設(shè)計，即很多功能塊可以獨立的加上或卸下，開發(fā)人員在設(shè)計內(nèi)核時把這些內(nèi)核模塊作為可選的選項，可以在編譯系統(tǒng)內(nèi)核時指定。因此一種較通用的做法是對 Linux 內(nèi)核重新編譯，在編譯時仔細的選擇嵌入式設(shè)備所需要的功能支持模塊，同時刪除不需要的功能。通過對內(nèi)核的重新配置，可以使系統(tǒng)運行所需要的內(nèi)核顯著減小，從而縮減資源使用量。

2. 制作 root 文件系統(tǒng)映象

Linux 系統(tǒng)在啟動時必須加載根(root)文件系統(tǒng)，因此剪裁系統(tǒng)同時包括 root file system 的剪裁。在 x86 系統(tǒng)下，Linux 可以在 Dos 下，使用 Loadlin 文件加載啟動，

uClinux 采用的小型化方法

1.uClinux 的內(nèi)核加載方式

uClinux 的內(nèi)核有兩種可選的運行方式：可以在 flash 上直接運行，也可以加載到內(nèi)存中運行。這種做法可以減少內(nèi)存需要。

Flash 運行方式：把內(nèi)核的可執(zhí)行映象燒寫到 flash 上，系統(tǒng)啟動時從 flash 的某個地址開始逐句執(zhí)行。這種方法實際上是很多嵌入式系統(tǒng)采用的方法。

內(nèi)核加載方式：把內(nèi)核的壓縮文件存放在 flash 上，系統(tǒng)啟動時讀取壓縮文件在內(nèi)存里解壓，然后開始執(zhí)行，這種方式相對復(fù)雜一些，但是運行速度可能更快(ram 的存取速率要比 flash 高)。同時這也是標準 Linux 系統(tǒng)采用的啟動方式。

2.uClinux 的根(root)文件系統(tǒng)

uClinux 系統(tǒng)采用 romfs 文件系統(tǒng)，這種文件系統(tǒng)相對于一般的 ext2 文件系統(tǒng)要求更少的空間?？臻g的節(jié)約來自于兩個方面，首先內(nèi)核支持 romfs 文件系統(tǒng)比支持 ext2 文件系統(tǒng)需要更少的代碼，其次 romfs 文件系統(tǒng)相對簡單，在建立文件系統(tǒng)超級塊(superblock)需要更少的存儲空間。Romfs 文件系統(tǒng)不支持動態(tài)擦寫保存，對于系統(tǒng)需要動態(tài)保存的數(shù)據(jù)采用虛擬 ram 盤的方法進行處理(ram 盤將采用 ext2 文件系統(tǒng))。

3.uClinux 的應(yīng)用程序庫

uClinux 小型化的另一個做法是重寫了應(yīng)用程序庫，相對于越來越大且越來越全的 glibc 庫，uClibc 對 libc 做了精簡。

uClinux 對用戶程序采用靜態(tài)連接的形式，這種做法會使應(yīng)用程序變大，但是基于內(nèi)存管理的問題，不得不這樣做(這將在下文對 uClinux 內(nèi)存管理展開分析時進行說明)，同時這種做法也更接近于通常嵌入式系統(tǒng)的做法。

系統(tǒng)特點

嵌入式操作系統(tǒng)比較

由表 1 可以看出，對于嵌入式應(yīng)用，高端平臺可直接采用 Linux 系統(tǒng)，其兼容性和可移植度都較高，但對硬件處理速度和存儲空間要求較高。

低端平臺的最佳選擇是 uClinux，其性能穩(wěn)定、移植性好、功能強大。

低端平臺如果對實時性要求較高、應(yīng)用相對簡單，則可采用 uc/os 或其他操作系統(tǒng)。

基本架構(gòu)

uClinux 的系統(tǒng)與標準 Linux 的架構(gòu)完全一致。

文件系統(tǒng)

uClinux 系統(tǒng)多采用 Romfs 文件系統(tǒng)，Romfs 是一種相對簡單、占用空間較少的文件系統(tǒng)?？臻g的節(jié)約來自于兩個方面：首先內(nèi)核支持 Romfs 文件系統(tǒng)比支持 ext2 文件系統(tǒng)需要更少的代碼;其次 romfs 文件系統(tǒng)相對簡單，在建立文件系統(tǒng)超級塊(Superblock)需要更少的存儲空間。Romfs 是只讀的文件系統(tǒng)，禁止寫操作，因此系統(tǒng)同時需要虛擬盤(RAMDISK)支持臨時文件和數(shù)據(jù)文件的存儲。

隨著技術(shù)的發(fā)展，近年來日志文件系統(tǒng)在 uClinux 系統(tǒng)上得到了較多的應(yīng)用，其中以支持 NOR FLASH 的 JFFS、JFFS2 文件系統(tǒng)和支持 NAND FLASH 的 YAFFS 最為流行。這些文件系統(tǒng)都支持掉電文件保護，同時支持標準的 MTD 驅(qū)動。

開發(fā)環(huán)境

GNU 開發(fā)套件

Gnu 開發(fā)套件作為通用的 Linux 開放套件，包括一系列的開發(fā)調(diào)試工具。主要組件：

Gcc： 編譯器，可以做成交叉編譯的形式，即在宿主機上開發(fā)編譯目標上可運行的二進制文件。

Binutils：一些輔助工具，包括 objdump(可以反編譯二進制文件)，as(匯編編譯器)，ld(連接器)等等。

Gdb：調(diào)試器，可使用多種交叉調(diào)試方式，gdb-bdm(背景調(diào)試工具)，gdbserver(使用以太網(wǎng)絡(luò)調(diào)試)。

uClinux 的打印終端

通常情況下，uClinux 的默認終端是串口，內(nèi)核在啟動時所有的信息都打印到串口終端(使用 printk 函數(shù)打印)，同時也可以通過串口終端與系統(tǒng)交互。

uClinux 在啟動時啟動了 telnetd(遠程登錄服務(wù))，操作者可以遠程登錄上系統(tǒng)，從而控制系統(tǒng)的運行。至于是否允許遠程登錄可以通過燒寫 romfs 文件系統(tǒng)時有用戶決定是否啟動遠程登錄服務(wù)。

交叉編譯調(diào)試工具

支持一種新的處理器，必須具備一些編譯，匯編工具，使用這些工具可以形成可運行于這種處理器的二進制文件。對于內(nèi)核使用的編譯工具同應(yīng)用程序使用的有所不同。在解釋不同點之前，需要對 gcc 連接做一些說明：

.ld(link description)文件：ld 文件是指出連接時內(nèi)存映象格式的文件。

crt0.S：應(yīng)用程序編譯連接時需要的啟動文件，主要是初始化應(yīng)用程序棧。

pic：position independence code ，與位置無關(guān)的二進制格式文件，在程序段中必須包括 reloc 段，從而使的代碼加載時可以進行重新定位。

內(nèi)核編譯連接時，使用 ucsimm.ld 文件，形成可執(zhí)行文件映象，所形成的代碼段既可以使用間接尋址方式(即使用 reloc 段進行尋址)，也可以使用絕對尋址方式。這樣可以給編譯器更多的優(yōu)化空間。因為內(nèi)核可能使用絕對尋址，所以內(nèi)核加載到的內(nèi)存地址空間必須與 ld 文件中給定的內(nèi)存空間完全相同。

應(yīng)用程序的連接與內(nèi)核連接方式不同。應(yīng)用程序由內(nèi)核加載(可執(zhí)行文件加載器將在后面討論)，由于應(yīng)用程序的 ld 文件給出的內(nèi)存空間與應(yīng)用程序?qū)嶋H被加載的內(nèi)存位置可能不同，這樣在應(yīng)用程序加載的過程中需要一個重新地位的過程，即對 reloc 段進行修正，使得程序進行間接尋址時不至于出錯。(這個問題在 i386 等高級處理器上方法有所不同，本文將在后面進一步分析)。

由上述討論，至少需要兩套編譯連接工具。在討論過 uClinux 的內(nèi)存管理后本文將給出整個系統(tǒng)的工作流程以及系統(tǒng)在 flash 和 ram 中的空間分布。

可執(zhí)行文件格式

先對一些名詞作一些說明：

coff(common object file format)：一種通用的對象文件格式

elf(excutive linked file)：一種為 Linux 系統(tǒng)所采用的通用文件格式，支持動態(tài)連接

flat：elf 格式有很大的文件頭，flat 文件對文件頭和一些段信息做了簡化

uClinux 系統(tǒng)使用 flat 可執(zhí)行文件格式，gcc 的編譯器不能直接形成這種文件格式，但是可以形成 coff 或 elf 格式的可執(zhí)行文件，這兩種文件需要 coff2flt 或 elf2flt 工具進行格式轉(zhuǎn)化，形成 flat 文件。

當用戶執(zhí)行一個應(yīng)用時，內(nèi)核的執(zhí)行文件加載器將對 flat 文件進行進一步處理，主要是對 reloc 段進行修正(可執(zhí)行文件加載器的詳見 fs/binfmt_flat.c)。以下對 reloc 段進一步討論。

需要 reloc 段的根本原因是，程序在連接時連接器所假定的程序運行空間與實際程序加載到的內(nèi)存空間不同。假如有這樣一條指令：

jsr app_start;

這一條指令采用直接尋址，跳轉(zhuǎn)到 app_start 地址處執(zhí)行，連接程序?qū)⒃诰幾g完成是計算出 app_start 的實際地址(設(shè)若實際地址為 0x10000)，這個實際地址是根據(jù) ld 文件計算出來(因為連接器假定該程序?qū)⒈患虞d到由 ld 文件指明的內(nèi)存空間)。但實際上由于內(nèi)存分配的關(guān)系，操作系統(tǒng)在加載時無法保證程序?qū)?ld 文件加載。這時如果程序仍然跳轉(zhuǎn)到絕對地址 0x10000 處執(zhí)行，通常情況這是不正確的。一個解決辦法是增加一個存儲空間，用于存儲 app_start 的實際地址，設(shè)若使用變量 addr 表示這個存儲空間。則以上這句程序?qū)⒏臑椋?/p>

movl addr, a0;

jsr (a0);

增加的變量 addr 將在數(shù)據(jù)段中占用一個 4 字節(jié)的空間，連接器將 app_start 的絕對地址存儲到該變量。在可執(zhí)行文件加載時，可執(zhí)行文件加載器根據(jù)程序?qū)⒁虞d的內(nèi)存空間計算出 app_start 在內(nèi)存中的實際位置，寫入 addr 變量。系統(tǒng)在實際處理是不需要知道這個變量的確切存儲位置(也不可能知道)，系統(tǒng)只要對整個 reloc 段進行處理就可以了(reloc 段有標識，系統(tǒng)可以讀出來)。處理很簡單只需要對 reloc 段中存儲的值統(tǒng)一加上一個偏置(如果加載的空間比預(yù)想的要靠前，實際上是減去一個偏移量)。偏置由實際的物理地址起始值同 ld 文件指定的地址起始值相減計算出。

這種 reloc 的方式部分是由 uClinux 的內(nèi)存分配問題引起的，這一點將在 uClinux 內(nèi)存管理分析時說明。

針對實時性的解決方案

uClinux 本身并沒有關(guān)注實時問題，它并不是為了 Linux 的實時性而提出的。另外有一種 Linux–Rt-linux 關(guān)注實時問題。Rt-linux 執(zhí)行管理器把普通 Linux 的內(nèi)核當成一個任務(wù)運行，同時還管理了實時進程。而非實時進程則交給普通 Linux 內(nèi)核處理。這種方法已經(jīng)應(yīng)用于很多的操作系統(tǒng)用于增強操作系統(tǒng)的實時性，包括一些商用版 UNIX 系統(tǒng)，Windows NT 等等。這種方法優(yōu)點之一是實現(xiàn)簡單，且實時性能容易檢驗。優(yōu)點之二是由于非實時進程運行于標準 Linux 系統(tǒng)，同其它 Linux 商用版本之間保持了很大的兼容性。優(yōu)點之三是可以支持硬實時時鐘的應(yīng)用。uClinux 可以使用 Rt-linux 的 patch，從而增強 uClinux 的實時性，使得 uClinux 可以應(yīng)用于工業(yè)控制、進程控制等一些實時要求較高的應(yīng)用。

內(nèi)存管理

應(yīng)該說 uClinux 同標準 Linux 的最大區(qū)別就在于內(nèi)存管理，同時也由于 uClinux 的內(nèi)存管理引發(fā)了一些標準 Linux 所不會出現(xiàn)的問題。本文將把 uClinux 內(nèi)存管理同標準 Linux 的內(nèi)存管理部分進行比較分析。

標準 Linux 使用的虛擬存儲器技術(shù)

標準 Linux 使用虛擬存儲器技術(shù)，這種技術(shù)用于提供比計算機系統(tǒng)中實際使用的物理內(nèi)存大得多的內(nèi)存空間。使用者將感覺到好像程序可以使用非常大的內(nèi)存空間，從而使得編程人員在寫程序時不用考慮計算機中的物理內(nèi)存的實際容量。為了支持虛擬存儲管理器的管理，Linux 系統(tǒng)采用分頁(paging)的方式來載入進程。所謂分頁既是把實際的存儲器分割為相同大小的段，例如每個段 1024 個字節(jié)，這樣 1024 個字節(jié)大小的段便稱為一個頁面(page)。

虛擬存儲器由存儲器管理機制及一個大容量的快速硬盤存儲器支持。它的實現(xiàn)基于局部性原理，當一個程序在運行之前，沒有必要全部裝入內(nèi)存，而是僅將那些當前要運行的那些部分頁面或段裝入內(nèi)存運行(copy-on-write)，其余暫時留在硬盤上程序運行時如果它所要訪問的頁(段)已存在，則程序繼續(xù)運行，如果發(fā)現(xiàn)不存在的頁(段)，操作系統(tǒng)將產(chǎn)生一個頁錯誤(page fault)，這個錯誤導(dǎo)致操作系統(tǒng)把需要運行的部分加載到內(nèi)存中。必要時操作系統(tǒng)還可以把不需要的內(nèi)存頁(段)交換到磁盤上。利用這樣的方式管理存儲器，便可把一個進程所需要用到的存儲器以化整為零的方式，視需求分批載入，而核心程序則憑借屬于每個頁面的頁碼來完成尋址各個存儲器區(qū)段的工作。

標準 Linux 是針對有內(nèi)存管理單元的處理器設(shè)計的。在這種處理器上，虛擬地址被送到內(nèi)存管理單元(MMU)，把虛擬地址映射為物理地址。

通過賦予每個任務(wù)不同的虛擬–物理地址轉(zhuǎn)換映射，支持不同任務(wù)之間的保護。地址轉(zhuǎn)換函數(shù)在每一個任務(wù)中定義，在一個任務(wù)中的虛擬地址空間映射到物理內(nèi)存的一個部分，而另一個任務(wù)的虛擬地址空間映射到物理存儲器中的另外區(qū)域。計算機的存儲管理單元(MMU)一般有一組寄存器來標識當前運行的進程的轉(zhuǎn)換表。在當前進程將 CPU 放棄給另一個進程時(一次上下文切換)，內(nèi)核通過指向新進程地址轉(zhuǎn)換表的指針加載這些寄存器。MMU 寄存器是有特權(quán)的，只能在內(nèi)核態(tài)才能訪問。這就保證了一個進程只能訪問自己用戶空間內(nèi)的地址，而不會訪問和修改其它進程的空間。當可執(zhí)行文件被加載時，加載器根據(jù)缺省的 ld 文件，把程序加載到虛擬內(nèi)存的一個空間，因為這個原因?qū)嶋H上很多程序的虛擬地址空間是相同的，但是由于轉(zhuǎn)換函數(shù)不同，所以實際所處的內(nèi)存區(qū)域也不同。而對于多進程管理當處理器進行進程切換并執(zhí)行一個新任務(wù)時，一個重要部分就是為新任務(wù)切換任務(wù)轉(zhuǎn)換表。我們可以看到 Linux 系統(tǒng)的內(nèi)存管理至少實現(xiàn)了以下功能：

運行比內(nèi)存還要大的程序。理想情況下應(yīng)該可以運行任意大小的程序

◇可以運行只加載了部分的程序，縮短了程序啟動的時間

◇可以使多個程序同時駐留在內(nèi)存中提高 CPU 的利用率

◇可以運行重定位程序。即程序可以方于內(nèi)存中的任何一處，而且可以在執(zhí)行過程中移動。

◇寫機器無關(guān)的代碼。程序不必事先約定機器的配置情況。

◇減輕程序員分配和管理內(nèi)存資源的負擔。

◇可以進行共享–例如，如果兩個進程運行同一個程序，它們應(yīng)該可以共享程序代碼的同一個副本。

◇提供內(nèi)存保護，進程不能以非授權(quán)方式訪問或修改頁面，內(nèi)核保護單個進程的數(shù)據(jù)和代碼以防止其它進程修改它們。否則，用戶程序可能會偶然(或惡意)的破壞內(nèi)核或其它用戶程序。

虛存系統(tǒng)并不是沒有代價的。內(nèi)存管理需要地址轉(zhuǎn)換表和其他一些數(shù)據(jù)結(jié)構(gòu)，留給程序的內(nèi)存減少了。地址轉(zhuǎn)換增加了每一條指令的執(zhí)行時間，而對于有額外內(nèi)存操作的指令會更嚴重。當進程訪問不在內(nèi)存的頁面時，系統(tǒng)發(fā)生失效。系統(tǒng)處理該失效，并將頁面加載到內(nèi)存中，這需要極耗時間的磁盤 I/O 操作。總之內(nèi)存管理活動占用了相當一部分 cpu 時間(在較忙的系統(tǒng)中大約占 10%)。

uClinux 針對 NOMMU 的特殊處理

對于 uClinux 來說，其設(shè)計針對沒有 MMU 的處理器，即 uClinux 不能使用處理器的虛擬內(nèi)存管理技術(shù)(應(yīng)該說這種不帶有 MMU 的處理器在嵌入式設(shè)備中相當普偏)。uClinux 仍然采用存儲器的分頁管理，系統(tǒng)在啟動時把實際存儲器進行分頁。在加載應(yīng)用程序時程序分頁加載。但是由于沒有 MMU 管理，所以實際上 uClinux 采用實存儲器管理策略(real memeory management)。這一點影響了系統(tǒng)工作的很多方面。

uClinux 系統(tǒng)對于內(nèi)存的訪問是直接的，(它對地址的訪問不需要經(jīng)過 MMU，而是直接送到地址線上輸出)，所有程序中訪問的地址都是實際的物理地址。操作系統(tǒng)對內(nèi)存空間沒有保護(這實際上是很多嵌入式系統(tǒng)的特點)，各個進程實際上共享一個運行空間(沒有獨立的地址轉(zhuǎn)換表)。

一個進程在執(zhí)行前，系統(tǒng)必須為進程分配足夠的連續(xù)地址空間，然后全部載入主存儲器的連續(xù)空間中。與之相對應(yīng)的是標準 Linux 系統(tǒng)在分配內(nèi)存時沒有必要保證實際物理存儲空間是連續(xù)的，而只要保證虛存地址空間連續(xù)就可以了。另外一個方面程序加載地址與預(yù)期(ld 文件中指出的)通常都不相同，這樣 relocation 過程就是必須的。此外磁盤交換空間也是無法使用的，系統(tǒng)執(zhí)行時如果缺少內(nèi)存將無法通過磁盤交換來得到改善。

uClinux 對內(nèi)存的管理減少同時就給開發(fā)人員提出了更高的要求。如果從易用性這一點來說，uClinux 的內(nèi)存管理是一種倒退，退回了到了 UNIX 早期或是 Dos 系統(tǒng)時代。開發(fā)人員不得不參與系統(tǒng)的內(nèi)存管理。從編譯內(nèi)核開始，開發(fā)人員必須告訴系統(tǒng)這塊開發(fā)板到底擁有多少的內(nèi)存(假如你欺騙了系統(tǒng)，那將在后面運行程序時受到懲罰)，從而系統(tǒng)將在啟動的初始化階段對內(nèi)存進行分頁，并且標記已使用的和未使用的內(nèi)存。系統(tǒng)將在運行應(yīng)用時使用這些分頁內(nèi)存。

由于應(yīng)用程序加載時必須分配連續(xù)的地址空間，而針對不同硬件平臺的可一次成塊(連續(xù)地址)分配內(nèi)存大小限制是不同(目前針對 ez328 處理器的 uClinux 是 128k，而針對 coldfire 處理器的系統(tǒng)內(nèi)存則無此限制)，所以開發(fā)人員在開發(fā)應(yīng)用程序時必須考慮內(nèi)存的分配情況并關(guān)注應(yīng)用程序需要運行空間的大小。另外由于采用實存儲器管理策略，用戶程序同內(nèi)核以及其它用戶程序在一個地址空間，程序開發(fā)時要保證不侵犯其它程序的地址空間，以使得程序不至于破壞系統(tǒng)的正常工作，或?qū)е缕渌绦虻倪\行異常。

從內(nèi)存的訪問角度來看，開發(fā)人員的權(quán)利增大了(開發(fā)人員在編程時可以訪問任意的地址空間)，但與此同時系統(tǒng)的安全性也大為下降。此外，系統(tǒng)對多進程的管理將有很大的變化，這一點將在 uClinux 的多進程管理中說明。

雖然 uClinux 的內(nèi)存管理與標準 Linux 系統(tǒng)相比功能相差很多，但應(yīng)該說這是嵌入式設(shè)備的選擇。在嵌入式設(shè)備中，由于成本等敏感因素的影響，普偏的采用不帶有 MMU 的處理器，這決定了系統(tǒng)沒有足夠的硬件支持實現(xiàn)虛擬存儲管理技術(shù)。從嵌入式設(shè)備實現(xiàn)的功能來看，嵌入式設(shè)備通常在某一特定的環(huán)境下運行，只要實現(xiàn)特定的功能，其功能相對簡單，內(nèi)存管理的要求完全可以由開發(fā)人員考慮。

標準 Linux 系統(tǒng)的進程、線程

進程：進程是一個運行程序并為其提供執(zhí)行環(huán)境的實體，它包括一個地址空間和至少一個控制點，進程在這個地址空間上執(zhí)行單一指令序列。進程地址空間包括可以訪問或引用的內(nèi)存單元的集合，進程控制點通過一個一般稱為程序計數(shù)器(program counter,PC)的硬件寄存器控制和跟蹤進程指令序列。

fork：由于進程為執(zhí)行程序的環(huán)境，因此在執(zhí)行程序前必須先建立這個能”跑”程序的環(huán)境。Linux 系統(tǒng)提供系統(tǒng)調(diào)用拷貝現(xiàn)行進程的內(nèi)容，以產(chǎn)生新的進程，調(diào)用 fork 的進程稱為父進程;而所產(chǎn)生的新進程則稱為子進程。子進程會承襲父進程的一切特性，但是它有自己的數(shù)據(jù)段，也就是說，盡管子進程改變了所屬的變量，卻不會影響到父進程的變量值。

父進程和子進程共享一個程序段，但是各自擁有自己的堆棧、數(shù)據(jù)段、用戶空間以及進程控制塊。換言之，兩個進程執(zhí)行的程序代碼是一樣的，但是各有各的程序計數(shù)器與自己的私人數(shù)據(jù)。

當內(nèi)核收到 fork 請求時，它會先查核三件事：首先檢查存儲器是不是足夠;其次是進程表是否仍有空缺;最后則是看看用戶是否建立了太多的子進程。如果上述說三個條件滿足，那么操作系統(tǒng)會給子進程一個進程識別碼，并且設(shè)定 cpu 時間，接著設(shè)定與父進程共享的段，同時將父進程的 inode 拷貝一份給子進程運用，最終子進程會返回數(shù)值 0 以表示它是子進程，至于父進程，它可能等待子進程的執(zhí)行結(jié)束，或與子進程各做個的。

exec 系統(tǒng)調(diào)用：該系統(tǒng)調(diào)用提供一個進程去執(zhí)行另一個進程的能力，exec 系統(tǒng)調(diào)用是??序的堆棧、數(shù)據(jù)段與程序段都會被修改，只有用戶區(qū)維持不變。

vfork 系統(tǒng)調(diào)用：由于在使用 fork 時，內(nèi)核會將父進程拷貝一份給子進程，但是這樣的做法相當浪費時間，因為大多數(shù)的情形都是程序在調(diào)用 fork 后就立即調(diào)用 exec，這樣剛拷貝來的進程區(qū)域又立即被新的數(shù)據(jù)覆蓋掉。因此 Linux 系統(tǒng)提供一個系統(tǒng)調(diào)用 vfork，vfork 假定系統(tǒng)在調(diào)用完成 vfork 后會馬上執(zhí)行 exec，因此 vfork 不拷貝父進程的頁面，只是初始化私有的數(shù)據(jù)結(jié)構(gòu)與準備足夠的分頁表。這樣實際在 vfork 調(diào)用完成后父子進程事實上共享同一塊存儲器(在子進程調(diào)用 exec 或是 exit 之前)，因此子進程可以更改父進程的數(shù)據(jù)及堆棧信息，因此 vfork 系統(tǒng)調(diào)用完成后，父進程進入睡眠，直到子進程執(zhí)行 exec。當子進程執(zhí)行 exec 時，由于 exec 要使用被執(zhí)行程序的數(shù)據(jù)，代碼覆蓋子進程的存儲區(qū)域，這樣將產(chǎn)生寫保護錯誤(do_wp_page)(這個時候子進程寫的實際上是父進程的存儲區(qū)域)，

這個錯誤導(dǎo)致內(nèi)核為子進程重新分配存儲空間。當子進程正確開始執(zhí)行后，將喚醒父進程，使得父進程繼續(xù)往后執(zhí)行。

uClinux 的多進程處理

uClinux 沒有 mmu 管理存儲器，在實現(xiàn)多個進程時(fork 調(diào)用生成子進程)需要實現(xiàn)數(shù)據(jù)保護。

uClinux 的 fork 和 vfork：uClinux 的 fork 等于 vfork。實際上 uClinux 的多進程管理通過 vfork 來實現(xiàn)。這意味著 uClinux 系統(tǒng) fork 調(diào)用完程后，要么子進程代替父進程執(zhí)行(此時父進程已經(jīng) sleep)直到子進程調(diào)用 exit 退出，要么調(diào)用 exec 執(zhí)行一個新的進程，這個時候?qū)a(chǎn)生可執(zhí)行文件的加載，即使這個進程只是父進程的拷貝，這個過程也不能避免。當子進程執(zhí)行 exit 或 exec 后，子進程使用 wakeup 把父進程喚醒，父進程繼續(xù)往下執(zhí)行。

uClinux 的這種多進程實現(xiàn)機制同它的內(nèi)存管理緊密相關(guān)。uClinux 針對 nommu 處理器開發(fā)，所以被迫使用一種 flat 方式的內(nèi)存管理模式，啟動新的應(yīng)用程序時系統(tǒng)必須為應(yīng)用程序分配存儲空間，并立即把應(yīng)用程序加載到內(nèi)存。缺少了 MMU 的內(nèi)存重映射機制，uClinux 必須在可執(zhí)行文件加載階段對可執(zhí)行文件 reloc 處理，使得程序執(zhí)行時能夠直接使用物理內(nèi)存。

uClinux 是專門針對沒有 MMU 的處理器而設(shè)計的，即 uClinux 無法使用處理器的虛擬內(nèi)存管理技術(shù)。實際上 uClinux 采用實存儲器管理策略，通過地址總線對物理內(nèi)存進行直接訪問。所有程序中訪問的地址都是實際的物理地址，所有的進程都在一個運行空間中運行(包括內(nèi)核進程)，這樣的運行機制給程序員帶來了不小的挑戰(zhàn)，在操作系統(tǒng)不提供保護的情況下必需小心設(shè)計程序和數(shù)據(jù)空間，以免引起應(yīng)用程序進程甚至是內(nèi)核的崩潰。

uClinux 仍然采用存儲器的分頁管理，系統(tǒng)在啟動時把實際存儲器進行分頁，在加載應(yīng)用程序時程序分頁加載。一個進程在執(zhí)行前，系統(tǒng)必須為進程分配足夠的連續(xù)地址空間，然后全部載入主存儲器的連續(xù)空間中。系統(tǒng)不含 MMU 帶來的另外一個問題是磁盤交換空間無法使用，對于資源有限的嵌入式系統(tǒng)而言，系統(tǒng)執(zhí)行時如果缺少內(nèi)存將無法通過磁盤交換來得到改善。

MMU 的省略雖然帶來了系統(tǒng)及應(yīng)用程序開發(fā)的限制，但對于成本和體積敏感的嵌入式設(shè)備而言，其應(yīng)用環(huán)境和應(yīng)用需求并不要求復(fù)雜和相對昂貴的硬件體系,對于功能簡單的專用嵌入式設(shè)備，內(nèi)存的分配和管理完全可以由開發(fā)人員考慮。

多進程管理

由于 uClinux 沒有 MMU 管理存儲器，在實現(xiàn)多個進程時需要實現(xiàn)數(shù)據(jù)保護。uClinux 的雖然支持 fork 函數(shù)，但其實質(zhì)是和 vfork：實際上 uClinux 所有的多進程管理都通過 vfork 來實現(xiàn)。

vfork 不拷貝父進程的頁面，只是初始化私有的數(shù)據(jù)結(jié)構(gòu)與準備足夠的分頁表。調(diào)用完成后父子進程事實上共享同一塊存儲器，因此子進程可以更改父進程的數(shù)據(jù)及堆棧信息，所有父進程進入睡眠，直到子進程執(zhí)行 exec。當子進程正確開始執(zhí)行后，將喚醒父進程，使得父進程繼續(xù)往后執(zhí)行。這意味著 uClinux 系統(tǒng) fork 調(diào)用完成后，要么子進程代替父進程執(zhí)行(此時父進程已經(jīng)休眠)直到子進程調(diào)用 exit 退出，要么調(diào)用 exec 執(zhí)行一個新的進程。

vfork 是 uClinux 與標準 Linux 應(yīng)用程序的開發(fā)中最重要的不同之處，只有對 vfork 與 fork 兩個函數(shù)的差異和程序處理有詳細的了解才能順利地完成從 Linux 到 uClinux 的程序移植。

缺點

正如古語云“人無完人”，uClinux 也有一些不足之處：

文檔的不足

與 Linux 及其他自由軟件類似，uClinux 的文檔十分不足：缺乏組織和一致的文檔、熱門技術(shù)和分類文檔眾多而雜亂無章、非熱點部分文檔缺失甚至沒有文檔。對于開發(fā)人員而言，往往要深入程序的源代碼找尋有用的資料。

Bug 問題

uClinux 與硬件平臺直接相關(guān)。對于有商業(yè)公司贊助的硬件平臺，其相關(guān)代碼和 Bug 更新較快，編譯和執(zhí)行都十分順利;但對于非商業(yè)支持的硬件平臺，其內(nèi)核和應(yīng)用程序代碼都得不到及時更新和排錯。這種現(xiàn)象在內(nèi)核源代碼樹還不是十分普遍，但在 uClinux 自帶的應(yīng)用程序庫中卻經(jīng)常發(fā)生編譯錯誤，往往是增加了一個應(yīng)用程序或改變了運行庫便導(dǎo)致無法編譯。這就需要開發(fā)者投入足夠的時間和精力進行排錯和修改，也會導(dǎo)致開發(fā)進度的延誤。

以上就是關(guān)于uCLinux是什么及uCLinux有什么用這方面的一些信息了 小編整理的這些訊息希望對童鞋們有所幫助