簡介
Linux是一種很受歡迎的操作系統，它與UNIX系統兼容，開放源代碼。它原本被設計為桌面系統，現在廣泛應用于服務器領域。而更大的影響在于它正逐漸的應用于嵌入式設備。uClinux正是在這種氛圍下産生的。在uClinux這個英文單詞中u表示Micro，小的意思，C表示Control，控制的意思，所以uClinux就是Micro-Control-Linux，字面上的理解就是"針對微控制領域而設計的Linux系統"。
uClinux是嵌入式Linux領域非常重要的分支，已成功應用于路由器、機頂盒、PDA等領域，與标準Linux在内存管理方面有着本質的區别。
uCLinux是一種優秀的嵌入式Linux版本，是micro-Conrol-Linux的縮寫。它秉承了标準Linux的優良特性，經過各方面的小型化改造，形成了一個高度優化的、代碼緊湊的嵌入式Linux。雖然它的體積很小，卻仍然保留了Linux的大多數的優點：穩定、良好的移植性、優秀的網絡功能、對各種文件系統完備的支持和标準豐富的API。它專為嵌入式系統做了許多小型化的工作，目前已支持多款CPU。其編譯後目标文件可控制在幾百KB數量級，并已經被成功地移植到很多平台上。
uClinux從Linux 2.0/2.4内核派生而來,沿襲了Linux的絕大部分特性。它是專門針對沒有MMU(内存管理單元)的CPU,并且為嵌入式系統做了許多小型化的工作。它通常用于具有很少内存或Flash的嵌入式操作系統。在GNU通用許可證的保證下,運行uClinux操作系統的用戶可以使用幾乎所有的Linux API函數。由于經過了裁剪和優化,它形成了一個高度優化,代碼緊湊的嵌入式Linux。它具有體積小、穩定、良好的移植性、優秀的網絡功能、完備的對各種文件系統的支持，以及豐富的API函數等優點。uClinux與Linux在兼容性方面表現出色，uClinux除了不能實現fork()外，其餘uClinux的API函數與标準Linux完全相同。
針對沒有MMU的CPU
全球每年生産的CPU的數量大概在二十億顆左右，其中大部分是應用于專用性很強的各類嵌入式系統。大部分嵌入式系統為了減少系統複雜程度、降低硬件及開發成本和運行功耗，在硬件設計中取消了内存管理單元（MMU）模塊。最初，運行于這類沒有MMU的CPU之上的都是一些很簡單的單任務操作系統，或者更簡單的控制程序，甚至根本就沒有操作系統而直接運行應用程序。在這種情況下，系統無法運行複雜的應用程序，或者效率很低，并且所有的應用程序需要重新開發，還要求開發人員十分了解硬件特性。這些都阻礙了不含MMU的嵌入式産品開發的速度和應用水平。
uClinux專門針對沒有MMU的CPU，并且為嵌入式系統做了許多小型化的工作。uClinux是一個完全符合GNU/GPL公約的項目，完全開放代碼。
最初的uClinux僅僅支持Palm硬件系統，基于Linux 2.0内核。随着系統的日益改進，支持的内核版本從2.0、2.2、2.4一直到現在最新的2.6。系統的開發人員從兩人增加到了目前的12人，支持的硬件系統也從一種增加到了目前的十餘種（支持的硬件平台如Motorola公司的M68328、M68EN322、MC68360、DragonBall系列如68EZ328、68VZ328，ColdFire系列的如5272、5307，ARM 7TDMI、MC68EN302、ETRAX、Intel i960、PRISMA、Atari 68k等等。）
根據Linuxdevices網站2004年3月的調查，uClinux在全球嵌入式Linux市場所占的份額已位居第二，僅僅落後于定制Linux（即自己下載源碼進行修改定制）。同時Linux在全球嵌入式操作系統的市場份額依然處于統治地位(占40%以上),領先第二名微軟公司的嵌入式操作系統三倍以上(市場份額約13%)。
特點
标準Linux可能采用的小型化方法
1.重新編譯内核
Linux内核采用模塊化的設計，即很多功能塊可以獨立的加上或卸下，開發人員在設計内核時把這些内核模塊作為可選的選項，可以在編譯系統内核時指定。因此一種較通用的做法是對Linux内核重新編譯，在編譯時仔細的選擇嵌入式設備所需要的功能支持模塊，同時删除不需要的功能。通過對内核的重新配置，可以使系統運行所需要的内核顯着減小，從而縮減資源使用量。
2.制作root文件系統映象
Linux系統在啟動時必須加載根（root）文件系統，因此剪裁系統同時包括root file system的剪裁。在x86系統下，Linux可以在Dos下，使用Loadlin文件加載啟動，
uClinux采用的小型化方法
1．uClinux的内核加載方式
uClinux的内核有兩種可選的運行方式：可以在flash上直接運行，也可以加載到内存中運行。這種做法可以減少内存需要。
Flash運行方式：把内核的可執行映象燒寫到flash上，系統啟動時從flash的某個地址開始逐句執行。這種方法實際上是很多嵌入式系統采用的方法。
内核加載方式：把内核的壓縮文件存放在flash上，系統啟動時讀取壓縮文件在内存裡解壓，然後開始執行，這種方式相對複雜一些，但是運行速度可能更快（ram的存取速率要比flash高）。同時這也是标準Linux系統采用的啟動方式。
2．uClinux的根（root）文件系統
uClinux系統采用romfs文件系統，這種文件系統相對于一般的ext2文件系統要求更少的空間。空間的節約來自于兩個方面，首先内核支持romfs文件系統比支持ext2文件系統需要更少的代碼，其次romfs文件系統相對簡單，在建立文件系統超級塊（superblock）需要更少的存儲空間。Romfs文件系統不支持動态擦寫保存，對于系統需要動态保存的數據采用虛拟ram盤的方法進行處理（ram盤将采用ext2文件系統）。
3．uClinux的應用程序庫
uClinux小型化的另一個做法是重寫了應用程序庫，相對于越來越大且越來越全的glibc庫，uClibc對libc做了精簡。
uClinux對用戶程序采用靜态連接的形式，這種做法會使應用程序變大，但是基于内存管理的問題，不得不這樣做（這将在下文對uClinux内存管理展開分析時進行說明），同時這種做法也更接近于通常嵌入式系統的做法。
系統特點
嵌入式操作系統比較
由表1可以看出，對于嵌入式應用，高端平台可直接采用Linux系統，其兼容性和可移植度都較高，但對硬件處理速度和存儲空間要求較高。
低端平台的最佳選擇是uClinux，其性能穩定、移植性好、功能強大。
低端平台如果對實時性要求較高、應用相對簡單，則可采用uc/os或其他操作系統。
文件系統
uClinux系統多采用Romfs文件系統，Romfs是一種相對簡單、占用空間較少的文件系統。空間的節約來自于兩個方面：首先内核支持Romfs文件系統比支持ext2文件系統需要更少的代碼；其次romfs文件系統相對簡單，在建立文件系統超級塊（Superblock）需要更少的存儲空間。Romfs是隻讀的文件系統，禁止寫操作，因此系統同時需要虛拟盤（RAMDISK）支持臨時文件和數據文件的存儲。
随着技術的發展，近年來日志文件系統在uClinux系統上得到了較多的應用，其中以支持NOR FLASH的JFFS、JFFS2文件系統和支持NAND FLASH的YAFFS最為流行。這些文件系統都支持掉電文件保護，同時支持标準的MTD驅動。
開發環境
GNU開發套件
Gnu開發套件作為通用的Linux開放套件，包括一系列的開發調試工具。主要組件：
Gcc：編譯器，可以做成交叉編譯的形式，即在宿主機上開發編譯目标上可運行的二進制文件。
Binutils：一些輔助工具，包括objdump（可以反編譯二進制文件），as（彙編編譯器），ld（連接器）等等。
Gdb：調試器，可使用多種交叉調試方式，gdb-bdm（背景調試工具），gdbserver（使用以太網絡調試）。
uClinux的打印終端
通常情況下，uClinux的默認終端是串口，内核在啟動時所有的信息都打印到串口終端（使用printk函數打印），同時也可以通過串口終端與系統交互。
uClinux在啟動時啟動了telnetd（遠程登錄服務），操作者可以遠程登錄上系統，從而控制系統的運行。至于是否允許遠程登錄可以通過燒寫romfs文件系統時有用戶決定是否啟動遠程登錄服務。
交叉編譯調試工具
支持一種新的處理器，必須具備一些編譯，彙編工具，使用這些工具可以形成可運行于這種處理器的二進制文件。對于内核使用的編譯工具同應用程序使用的有所不同。在解釋不同點之前，需要對gcc連接做一些說明：
.ld（link description）文件：ld文件是指出連接時内存映象格式的文件。
crt0.S：應用程序編譯連接時需要的啟動文件，主要是初始化應用程序棧。
pic：position independence code，與位置無關的二進制格式文件，在程序段中必須包括reloc段，從而使的代碼加載時可以進行重新定位。
内核編譯連接時，使用ucsimm.ld文件，形成可執行文件映象，所形成的代碼段既可以使用間接尋址方式（即使用reloc段進行尋址），也可以使用絕對尋址方式。這樣可以給編譯器更多的優化空間。因為内核可能使用絕對尋址，所以内核加載到的内存地址空間必須與ld文件中給定的内存空間完全相同。
應用程序的連接與内核連接方式不同。應用程序由内核加載（可執行文件加載器将在後面讨論），由于應用程序的ld文件給出的内存空間與應用程序實際被加載的内存位置可能不同，這樣在應用程序加載的過程中需要一個重新地位的過程，即對reloc段進行修正，使得程序進行間接尋址時不至于出錯。（這個問題在i386等高級處理器上方法有所不同，本文将在後面進一步分析）。
由上述讨論，至少需要兩套編譯連接工具。在讨論過uClinux的内存管理後本文将給出整個系統的工作流程以及系統在flash和ram中的空間分布。
可執行文件格式
先對一些名詞作一些說明：
coff（common object file format）：一種通用的對象文件格式
elf（excutive linked file）：一種為Linux系統所采用的通用文件格式，支持動态連接
flat：elf格式有很大的文件頭，flat文件對文件頭和一些段信息做了簡化
uClinux系統使用flat可執行文件格式，gcc的編譯器不能直接形成這種文件格式，但是可以形成coff或elf格式的可執行文件，這兩種文件需要coff2flt或elf2flt工具進行格式轉化，形成flat文件。
當用戶執行一個應用時，内核的執行文件加載器将對flat文件進行進一步處理，主要是對reloc段進行修正（可執行文件加載器的詳見fs/binfmt_flat.c）。
這一條指令采用直接尋址，跳轉到app_start地址處執行，連接程序将在編譯完成是計算出app_start的實際地址（設若實際地址為0x10000），這個實際地址是根據ld文件計算出來（因為連接器假定該程序将被加載到由ld文件指明的内存空間）。但實際上由于内存分配的關系，操作系統在加載時無法保證程序将按ld文件加載。這時如果程序仍然跳轉到絕對地址0x10000處執行，通常情況這是不正确的。一個解決辦法是增加一個存儲空間，用于存儲app_start的實際地址。
增加的變量addr将在數據段中占用一個4字節的空間，連接器将app_start的絕對地址存儲到該變量。在可執行文件加載時，可執行文件加載器根據程序将要加載的内存空間計算出app_start在内存中的實際位置，寫入addr變量。系統在實際處理是不需要知道這個變量的确切存儲位置（也不可能知道），系統隻要對整個reloc段進行處理就可以了（reloc段有标識，系統可以讀出來）。處理很簡單隻需要對reloc段中存儲的值統一加上一個偏置（如果加載的空間比預想的要靠前，實際上是減去一個偏移量）。偏置由實際的物理地址起始值同ld文件指定的地址起始值相減計算出。
這種reloc的方式部分是由uClinux的内存分配問題引起的，這一點将在uClinux内存管理分析時說明。
針對實時性的解決方案
uClinux本身并沒有關注實時問題，它并不是為了Linux的實時性而提出的。另外有一種Linux--Rt-linux關注實時問題。Rt-linux執行管理器把普通Linux的内核當成一個任務運行，同時還管理了實時進程。而非實時進程則交給普通Linux内核處理。這種方法已經應用于很多的操作系統用于增強操作系統的實時性，包括一些商用版UNIX系統，Windows NT等等。這種方法優點之一是實現簡單，且實時性能容易檢驗。優點之二是由于非實時進程運行于标準Linux系統，同其它Linux商用版本之間保持了很大的兼容性。優點之三是可以支持硬實時時鐘的應用。uClinux可以使用Rt-linux的patch，從而增強uClinux的實時性，使得uClinux可以應用于工業控制、進程控制等一些實時要求較高的應用。
内存管理
應該說uClinux同标準Linux的最大區别就在于内存管理，同時也由于uClinux的内存管理引發了一些标準Linux所不會出現的問題。本文将把uClinux内存管理同标準Linux的那内存管理部分進行比較分析。
标準Linux使用的虛拟存儲器技術
标準Linux使用虛拟存儲器技術，這種技術用于提供比計算機系統中實際使用的物理内存大得多的内存空間。使用者将感覺到好像程序可以使用非常大的内存空間，從而使得編程人員在寫程序時不用考慮計算機中的物理内存的實際容量。為了支持虛拟存儲管理器的管理，Linux系統采用分頁（paging）的方式來載入進程。所謂分頁既是把實際的存儲器分割為相同大小的段，例如每個段1024個字節，這樣1024個字節大小的段便稱為一個頁面（page）。
虛拟存儲器由存儲器管理機制及一個大容量的快速硬盤存儲器支持。它的實現基于局部性原理，當一個程序在運行之前，沒有必要全部裝入内存，而是僅将那些當前要運行的那些部分頁面或段裝入内存運行（copy-on-write），其餘暫時留在硬盤上程序運行時如果它所要訪問的頁（段）已存在，則程序繼續運行，如果發現不存在的頁（段），操作系統将産生一個頁錯誤（page fault），這個錯誤導緻操作系統把需要運行的部分加載到内存中。必要時操作系統還可以把不需要的内存頁（段）交換到磁盤上。利用這樣的方式管理存儲器，便可把一個進程所需要用到的存儲器以化整為零的方式，視需求分批載入，而核心程序則憑借屬于每個頁面的頁碼來完成尋址各個存儲器區段的工作。
标準Linux是針對有内存管理單元的處理器設計的。在這種處理器上，虛拟地址被送到内存管理單元（MMU），把虛拟地址映射為物理地址。
通過賦予每個任務不同的虛拟--物理地址轉換映射，支持不同任務之間的保護。地址轉換函數在每一個任務中定義，在一個任務中的虛拟地址空間映射到物理内存的一個部分，而另一個任務的虛拟地址空間映射到物理存儲器中的另外區域。計算機的存儲管理單元（MMU）一般有一組寄存器來标識當前運行的進程的轉換表。在當前進程将CPU放棄給另一個進程時（一次上下文切換），内核通過指向新進程地址轉換表的指針加載這些寄存器。MMU寄存器是有特權的，隻能在内核态才能訪問。這就保證了一個進程隻能訪問自己用戶空間内的地址，而不會訪問和修改其它進程的空間。當可執行文件被加載時，加載器根據缺省的ld文件，把程序加載到虛拟内存的一個空間，因為這個原因實際上很多程序的虛拟地址空間是相同的，但是由于轉換函數不同，所以實際所處的内存區域也不同。而對于多進程管理當處理器進行進程切換并執行一個新任務時，一個重要部分就是為新任務切換任務轉換表。我們可以看到Linux系統的内存管理至少實現了以下功能：
運行比内存還要大的程序。理想情況下應該可以運行任意大小的程序
◇可以運行隻加載了部分的程序，縮短了程序啟動的時間
◇可以使多個程序同時駐留在内存中提高CPU的利用率
◇可以運行重定位程序。即程序可以方于内存中的任何一處，而且可以在執行過程中移動。
◇寫機器無關的代碼。程序不必事先約定機器的配置情況。
◇減輕程序員分配和管理内存資源的負擔。
◇可以進行共享--例如，如果兩個進程運行同一個程序，它們應該可以共享程序代碼的同一個副本。
◇提供内存保護，進程不能以非授權方式訪問或修改頁面，内核保護單個進程的數據和代碼以防止其它進程修改它們。否則，用戶程序可能會偶然（或惡意）的破壞内核或其它用戶程序。
虛存系統并不是沒有代價的。内存管理需要地址轉換表和其他一些數據結構，留給程序的内存減少了。地址轉換增加了每一條指令的執行時間，而對于有額外内存操作的指令會更嚴重。當進程訪問不在内存的頁面時，系統發生失效。系統處理該失效，并将頁面加載到内存中，這需要極耗時間的磁盤I/O操作。總之内存管理活動占用了相當一部分cpu時間（在較忙的系統中大約占10%）。
uClinux針對NOMMU的特殊處理
對于uClinux來說，其設計針對沒有MMU的處理器，即uClinux不能使用處理器的虛拟内存管理技術（應該說這種不帶有MMU的處理器在嵌入式設備中相當普偏）。uClinux仍然采用存儲器的分頁管理，系統在啟動時把實際存儲器進行分頁。在加載應用程序時程序分頁加載。但是由于沒有MMU管理，所以實際上uClinux采用實存儲器管理策略（real memeory management）。這一點影響了系統工作的很多方面。
uClinux系統對于内存的訪問是直接的，（它對地址的訪問不需要經過MMU，而是直接送到地址線上輸出），所有程序中訪問的地址都是實際的物理地址。操作系統對内存空間沒有保護（這實際上是很多嵌入式系統的特點），各個進程實際上共享一個運行空間（沒有獨立的地址轉換表）。
一個進程在執行前，系統必須為進程分配足夠的連續地址空間，然後全部載入主存儲器的連續空間中。與之相對應的是标準Linux系統在分配内存時沒有必要保證實際物理存儲空間是連續的，而隻要保證虛存地址空間連續就可以了。另外一個方面程序加載地址與預期（ld文件中指出的）通常都不相同，這樣relocation過程就是必須的。此外磁盤交換空間也是無法使用的，系統執行時如果缺少内存将無法通過磁盤交換來得到改善。
uClinux對内存的管理減少同時就給開發人員提出了更高的要求。如果從易用性這一點來說，uClinux的内存管理是一種倒退，退回了到了UNIX早期或是Dos系統時代。開發人員不得不參與系統的内存管理。從編譯内核開始，開發人員必須告訴系統這塊開發闆到底擁有多少的内存（假如你欺騙了系統，那将在後面運行程序時受到懲罰），從而系統将在啟動的初始化階段對内存進行分頁，并且标記已使用的和未使用的内存。系統将在運行應用時使用這些分頁内存。
由于應用程序加載時必須分配連續的地址空間，而針對不同硬件平台的可一次成塊（連續地址）分配内存大小限制是不同（目前針對ez328處理器的uClinux是128k，而針對coldfire處理器的系統内存則無此限制），所以開發人員在開發應用程序時必須考慮内存的分配情況并關注應用程序需要運行空間的大小。另外由于采用實存儲器管理策略，用戶程序同内核以及其它用戶程序在一個地址空間，程序開發時要保證不侵犯其它程序的地址空間，以使得程序不至于破壞系統的正常工作，或導緻其它程序的運行異常。
從内存的訪問角度來看，開發人員的權利增大了（開發人員在編程時可以訪問任意的地址空間），但與此同時系統的安全性也大為下降。此外，系統對多進程的管理将有很大的變化，這一點将在uClinux的多進程管理中說明。
雖然uClinux的内存管理與标準Linux系統相比功能相差很多，但應該說這是嵌入式設備的選擇。在嵌入式設備中，由于成本等敏感因素的影響，普偏的采用不帶有MMU的處理器，這決定了系統沒有足夠的硬件支持實現虛拟存儲管理技術。從嵌入式設備實現的功能來看，嵌入式設備通常在某一特定的環境下運行，隻要實現特定的功能，其功能相對簡單，内存管理的要求完全可以由開發人員考慮。
标準Linux系統的進程、線程
進程：進程是一個運行程序并為其提供執行環境的實體，它包括一個地址空間和至少一個控制點，進程在這個地址空間上執行單一指令序列。進程地址空間包括可以訪問或引用的内存單元的集合，進程控制點通過一個一般稱為程序計數器（program counter,PC）的硬件寄存器控制和跟蹤進程指令序列。
fork：由于進程為執行程序的環境，因此在執行程序前必須先建立這個能"跑"程序的環境。Linux系統提供系統調用拷貝現行進程的内容，以産生新的進程，調用fork的進程稱為父進程；而所産生的新進程則稱為子進程。子進程會承襲父進程的一切特性，但是它有自己的數據段，也就是說，盡管子進程改變了所屬的變量，卻不會影響到父進程的變量值。
父進程和子進程共享一個程序段，但是各自擁有自己的堆棧、數據段、用戶空間以及進程控制塊。換言之，兩個進程執行的程序代碼是一樣的，但是各有各的程序計數器與自己的私人數據。
當内核收到fork請求時，它會先查核三件事：首先檢查存儲器是不是足夠；其次是進程表是否仍有空缺；最後則是看看用戶是否建立了太多的子進程。如果上述說三個條件滿足，那麼操作系統會給子進程一個進程識别碼，并且設定cpu時間，接着設定與父進程共享的段，同時将父進程的inode拷貝一份給子進程運用，最終子進程會返回數值0以表示它是子進程，至于父進程，它可能等待子進程的執行結束，或與子進程各做個的。
exec系統調用：該系統調用提供一個進程去執行另一個進程的能力，exec系統調用是?序的堆棧、數據段與程序段都會被修改，隻有用戶區維持不變。
vfork系統調用：由于在使用fork時，内核會将父進程拷貝一份給子進程，但是這樣的做法相當浪費時間，因為大多數的情形都是程序在調用fork後就立即調用exec，這樣剛拷貝來的進程區域又立即被新的數據複蓋掉。因此Linux系統提供一個系統調用vfork，vfork假定系統在調用完成vfork後會馬上執行exec，因此vfork不拷貝父進程的頁面，隻是初始化私有的數據結構與準備足夠的分頁表。這樣實際在vfork調用完成後父子進程事實上共享同一塊存儲器（在子進程調用exec或是exit之前），因此子進程可以更改父進程的數據及堆棧信息，因此vfork系統調用完成後，父進程進入睡眠，直到子進程執行exec。當子進程執行exec時，由于exec要使用被執行程序的數據，代碼複蓋子進程的存儲區域，這樣将産生寫保護錯誤（do_wp_page）（這個時候子進程寫的實際上是父進程的存儲區域），
這個錯誤導緻内核為子進程重新分配存儲空間。當子進程正确開始執行後，将喚醒父進程，使得父進程繼續往後執行。
uClinux的多進程處理
uClinux沒有mmu管理存儲器，在實現多個進程時（fork調用生成子進程）需要實現數據保護。
uClinux的fork和vfork：uClinux的fork等于vfork。實際上uClinux的多進程管理通過vfork來實現。這意味着uClinux系統fork調用完程後，要麼子進程代替父進程執行（此時父進程已經sleep）直到子進程調用exit退出，要麼調用exec執行一個新的進程，這個時候将産生可執行文件的加載，即使這個進程隻是父進程的拷貝，這個過程也不能避免。當子進程執行exit或exec後，子進程使用wakeup把父進程喚醒，父進程繼續往下執行。
uClinux的這種多進程實現機制同它的内存管理緊密相關。uClinux針對nommu處理器開發，所以被迫使用一種flat方式的内存管理模式，啟動新的應用程序時系統必須為應用程序分配存儲空間，并立即把應用程序加載到内存。缺少了MMU的内存重映射機制，uClinux必須在可執行文件加載階段對可執行文件reloc處理，使得程序執行時能夠直接使用物理内存。
uClinux是專門針對沒有MMU的處理器而設計的，即uClinux無法使用處理器的虛拟内存管理技術。實際上uClinux采用實存儲器管理策略，通過地址總線對物理内存進行直接訪問。所有程序中訪問的地址都是實際的物理地址，所有的進程都在一個運行空間中運行（包括内核進程），這樣的運行機制給程序員帶來了不小的挑戰，在操作系統不提供保護的情況下必需小心設計程序和數據空間，以免引起應用程序進程甚至是内核的崩潰。
uClinux仍然采用存儲器的分頁管理，系統在啟動時把實際存儲器進行分頁，在加載應用程序時程序分頁加載。一個進程在執行前，系統必須為進程分配足夠的連續地址空間，然後全部載入主存儲器的連續空間中。系統不含MMU帶來的另外一個問題是磁盤交換空間無法使用，對于資源有限的嵌入式系統而言，系統執行時如果缺少内存将無法通過磁盤交換來得到改善。
MMU的省略雖然帶來了系統及應用程序開發的限制，但對于成本和體積敏感的嵌入式設備而言，其應用環境和應用需求并不要求複雜和相對昂貴的硬件體系,對于功能簡單的專用嵌入式設備，内存的分配和管理完全可以由開發人員考慮。
缺點
正如中國古語雲“人無完人”，uClinux也有一些不足之處：
文檔的不足
與Linux及其他自由軟件類似，uClinux的文檔十分不足：缺乏組織和一緻的文檔、熱門技術和分類文檔衆多而雜亂無章、非熱點部分文檔缺失甚至沒有文檔。對于開發人員而言，往往要深入程序的源代碼找尋有用的資料。
Bug問題
uClinux與硬件平台直接相關。對于有商業公司贊助的硬件平台，其相關代碼和Bug更新較快，編譯和執行都十分順利；但對于非商業支持的硬件平台，其内核和應用程序代碼都得不到及時更新和排錯。這種現象在内核源代碼樹還不是十分普遍，但在uClinux自帶的應用程序庫中卻經常發生編譯錯誤，往往是增加了一個應用程序或改變了運行庫便導緻無法編譯。這就需要開發者投入足夠的時間和精力進行排錯和修改，也會導緻開發進度的延誤。
實時性讨論
與Linux一樣，uClinux本身并不支持實時性應用，但通過實時性的修改（RTLinux或RTAI）可以提供基于内核空間和用戶空間的硬實時和軟實時的系統調用。
