為什么需要MMU ？??

我們知道應(yīng)用程序是不能隨意訪問內(nèi)存的，如果讓應(yīng)用程序直接訪問物理內(nèi)存，那么計(jì)算機(jī)是很危險(xiǎn)的，計(jì)算機(jī)內(nèi)存的所有內(nèi)容將被完全暴露出來。

所以出現(xiàn)了mmu，mmu是內(nèi)存管理單元，應(yīng)用程序訪問的是虛擬內(nèi)存，虛擬內(nèi)存夠通過mmu的轉(zhuǎn)換后，變成物理內(nèi)存，物理內(nèi)存對(duì)應(yīng)的就是實(shí)際上物理存儲(chǔ)磁盤上的地址。詳細(xì)講解MMU

主線的linux代碼，正常運(yùn)行是需要mmu機(jī)制的。

但是如果想運(yùn)行沒有mmu的linux內(nèi)核代碼也不是不可以，就需要進(jìn)行裁剪和配置，最困難的就是調(diào)試。

mmu模塊一般是CPU的一個(gè)內(nèi)部組成部分，當(dāng)然，也存在位置mmu的情況。

如果想運(yùn)行沒有mmu的linux內(nèi)核代碼，不妨看看uclinux。

什么是ucLinux ？??

在uClinux這個(gè)英文單詞中u表示Micro，小的意思，C表示Control，控制的意思， 所以u(píng)Clinux就是Micro-Control-Linux，字面上的理解就是"針對(duì)微控制領(lǐng)域而設(shè)計(jì)的Linux系統(tǒng)"。

uclinux和linux的區(qū)別

• 沒有虛存管理單元mmu

• 不能運(yùn)行時(shí)增加進(jìn)程棧

• 不支持分頁

• 可執(zhí)行程序不是elf, ? 而是flat

• 不能用fork, ? 而是用vfork

• RAMDISK

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

對(duì)uCLinux 來說，其設(shè)計(jì)針對(duì)沒有MMU的處理器，不能使用處理器的虛擬內(nèi)存管理技術(shù)。uCLinux仍然采用存儲(chǔ)器的分頁管理，系統(tǒng)在啟動(dòng)時(shí)把實(shí)際存儲(chǔ)器進(jìn)行分頁。在加載應(yīng)用程序時(shí)程序分頁加載。但是由于沒有MMU管理，所以實(shí)際上uCLinux采用實(shí)存儲(chǔ)器管理策略。

uCLinux系統(tǒng)對(duì)于內(nèi)存的訪問是直接的，所 有程序中訪問的地址都是實(shí)際的物理地址。操作系統(tǒng)對(duì)內(nèi)存空間沒有保護(hù)，各個(gè)進(jìn)程實(shí)際上共享一個(gè)運(yùn)行空間。

一個(gè)進(jìn)程在執(zhí)行前，系統(tǒng)必須為進(jìn)程分配足夠的連續(xù) 地址空間，然后全部載入主存儲(chǔ)器的連續(xù)空間中。

內(nèi)存保護(hù)??

沒有內(nèi)存保護(hù)(Memory Protection)的操作會(huì)導(dǎo)致這樣的結(jié)果：

即使由無特權(quán)的進(jìn)程來調(diào)用一個(gè)無效指針，也會(huì)觸發(fā)一個(gè)地址錯(cuò)誤，并潛在地引起程序崩潰，甚至導(dǎo)致系統(tǒng)的掛 起。顯然，在這樣的系統(tǒng)上運(yùn)行的代碼必須仔細(xì)編程，并深入測(cè)試來確保健壯性和安全。

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

虛擬內(nèi)存

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

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

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

由于uclinux中不使用虛擬內(nèi)存，進(jìn)出內(nèi)存的頁面交換也沒有實(shí)現(xiàn)，因?yàn)椴荒鼙ＷC頁面會(huì)被加載到RAM中的同樣位置。在普通計(jì)算機(jī)上，操作系統(tǒng)允 許應(yīng)用程序使用比物理內(nèi)存(RAM)更大的內(nèi)存空間，這往往是通過在硬盤上設(shè)立交換分區(qū)來實(shí)現(xiàn)的。但是，在嵌入式系統(tǒng)中，通常都用FLASH存儲(chǔ)器來代替 硬盤，很難高效地實(shí)現(xiàn)內(nèi)存頁面交換的存取，因此，對(duì)運(yùn)行的應(yīng)用程序都限制其可分配空間不大于系統(tǒng)的RAM空間。

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

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

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

uClinux 既沒有自動(dòng)生長(zhǎng)的堆棧，也沒有brk()函數(shù)，這樣，用戶空間的程序必須使用mmap() 命令來分配內(nèi)存。為了方便，在uclinux的C語言庫中所實(shí)現(xiàn)的malloc()實(shí)質(zhì)上就是一個(gè)mmap()。在編譯時(shí)，可以指定程序的堆棧大小。

最后，uClinux目標(biāo)板處理器缺乏內(nèi)存管理的硬件單元，使得Linux的系統(tǒng)接口需要作些改變。

有可能最大的不同就是沒有fork()和 brk()系統(tǒng)調(diào)用。調(diào)用fork()將復(fù)制出進(jìn)程來創(chuàng)建一個(gè)子進(jìn)程。在Linux下，fork()是使用copy-on-write頁面來實(shí)現(xiàn)的。由于 沒有MMU， uclinux不能完整、可地復(fù)制一個(gè)進(jìn)程，也沒有對(duì)copy-on-write的存取。

為了彌補(bǔ)這一缺陷，uClinux實(shí)現(xiàn)了vfork()，當(dāng)父 進(jìn)程調(diào)用vfork()來創(chuàng)建子進(jìn)程時(shí)，兩個(gè)進(jìn)程共享它們的全部?jī)?nèi)存空間，包括堆棧。

子進(jìn)程要么代替父進(jìn)程執(zhí)行（此時(shí)父進(jìn)程已經(jīng)sleep）直到子進(jìn)程調(diào) 用exitI()退出，要么調(diào)用exec()執(zhí)行一個(gè)新的進(jìn)程，這個(gè)時(shí)候?qū)a(chǎn)生可執(zhí)行文件的加載。即使這個(gè)進(jìn)程只是父進(jìn)程的拷貝，這個(gè)過程也不能避免。

當(dāng) 子進(jìn)程執(zhí)行exit()或exec()后，子進(jìn)程使用wakeup把父進(jìn)程喚醒，父進(jìn)程繼續(xù)往下執(zhí)行。

通用架構(gòu)的內(nèi)核變化:

在uCLinux的發(fā)布中,/linux/mmnommu目錄取代了/linux/mm目錄.前者是修改后的內(nèi)存管理子系統(tǒng) 被修改,去除了MMU的硬件依賴,并在內(nèi)核軟件自身提供基本的內(nèi)存管理函數(shù).

很多子系統(tǒng)需要重新修改,添加或重寫.內(nèi)核和用戶內(nèi)存分配及釋放進(jìn)程 必須重新實(shí)現(xiàn),對(duì)透明交互/頁面調(diào)度的支持也被去除. 內(nèi)核中,加入了支持"內(nèi)核無關(guān)代碼(PIC)"的程序支持模塊,并使用了新的二進(jìn)制目標(biāo)代碼 格式,稱扁平格式,用來支持PIC(有非常緊湊的頭部).

內(nèi)核也提供了支持ELF格式的程序加載模塊,用來支持使用固定基準(zhǔn)地址的可執(zhí)行程序.兩種模式各 有利弊,傳統(tǒng)的PIC運(yùn)行快,代碼緊湊,但有代碼大小限制.

例如Motorola 68K架構(gòu)的16位相對(duì)跳轉(zhuǎn)限制了PIC程序不能超過32KB大小,而采用運(yùn)行期固定基準(zhǔn)地址的方法上市的程序代碼沒有了大小限制,但當(dāng)陳旭被內(nèi)核加載后 導(dǎo)致了較多的系統(tǒng)開銷.

對(duì)于內(nèi)核開發(fā)者來說,uCLinux基本上與Linux沒有區(qū)別,唯一的區(qū)別就是不能利用MMU提供的內(nèi)存管理.實(shí)際上這對(duì)內(nèi)核并 沒有影響.?

Linux下所有標(biāo)準(zhǔn)的可執(zhí)行文件的格式在uCLinux并不被支持,因?yàn)檫@些格式也用到了虛擬內(nèi)存的一些功能.uCLinux使用的 是另外一種扁平格式.扁平格式是一種簡(jiǎn)潔高效的可執(zhí)行文件格式,它值包含可執(zhí)行的代碼和數(shù)據(jù),還有一些把可執(zhí)行文件加載到內(nèi)存任意位置所需要的可重定位的 信息.

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ?

零聲白金VIP體驗(yàn)卡（含基礎(chǔ)架構(gòu)/高性能存儲(chǔ)/golang/QT/音視頻/Linux內(nèi)核）課程：?

總結(jié)??

在應(yīng)用程序移植到uClinux， 以及自己寫代碼的過程中，我們將始終圍繞這幾個(gè)特性來做：

1、在configure時(shí)， 如果可能則需要在configure時(shí)，選上—disable-shared和—enable-static.

2、將源代碼中所有出現(xiàn)的fork()改成vfork();

3、在Makefile中 的交叉編譯器和編譯選項(xiàng)，鏈接選項(xiàng)里加上-Wl,-elf2flt。盡管這只是一個(gè)鏈接選項(xiàng)，但我 還是小心地在LDFLAGS和CFLAGS， 甚至在CC中指定了該選項(xiàng)。

改選項(xiàng)是將ELF格式轉(zhuǎn)換成uClinux所 能識(shí)別的FLAT格式。在做這個(gè)轉(zhuǎn)換過程，我們是不能對(duì)ELF文 件使用strip去除一些信息，更有甚者不能使用-O2 選 項(xiàng)來優(yōu)化代碼。因?yàn)槿サ舻哪承┬畔⒖赡軐?dǎo)致最終生成的FLAT格式文件運(yùn)行出現(xiàn)問題。

原文作者：一起學(xué)嵌入式