崁入式開發環境 - 減少footprint方式

jacky002

這篇是版主前陣子所寫的一篇文章，如果各位網友有其他的獨特見解與看法，歡迎一起加入來討論。

在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。
+ k  E1 p$ Y3 [: R為了要解決此類的問題 , 一般會有以下幾種作法:
! Z6 K/ t1 @4 m; D4 q3 w1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。
   此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.
   
0 ~3 R  l" h' q- v/ w' N# ?2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
9 K* u$ B3 W# Z, Z0 }4 _6 k   以下介紹三種不同的 C Library
   GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用
4 z( U$ L2 L6 C, p/ m       Pros: 函式庫支援最多而且沒有相容性問題
       Cons: 編譯出來的footprinte過大 不適用於產品量產化
   
   uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。
       Pros: 編譯出來的footprint很小 最適用於產品量產化
' ^! G8 G1 `" R7 @3 W       Cons: 函式庫支援較少而且會有相容性問題
   
# D4 ^7 p- F! Z; ?+ b* j' ^1 H   EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善
9 R) ~& X" b0 d" c3 h! ]4 N       Pros: 函式庫支援最多而且沒有相容性問題
9 U7 Q0 B5 U0 ]: M6 [7 x       Cons: 編譯出來的footprinte過大 不適用於產品量產化   
   
' c6 |" q( ?1 {# Y, f   基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:
* f& u0 x% f. c  J. G: {   Footprint size(由大到小): GLibc > EGLib >  uCLibc
& j( _& L0 O  v$ J   Compatibility (由最佳到次之): GLibc = EGLib >  uCLibc
   
3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。
   - 靜態連結 (Static link) vs.動態連結(Dynamic Link)
8 u% P" T' ~* t2 e& s! l     Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link)
     Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link)
     取決於所需與目的所在.
! x/ |2 |+ t( d) ]      
   - 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.
  K% k5 v& O( i; I, D0 {   
   - 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint
* g' m  g3 ?" y   
/ u7 l# j: J* q- \4 d$ b% \   - 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk.
( q0 u/ x: p- a! S- O2 g( [     Pros: 減少footprint size
* E% g7 \% Q, T' _0 W     Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間
; C- H( Y& {* ]5 ~  A) P; B/ k, H2 y     
; B' P* Z$ D! k7 z! _% U5 i     折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行.
. t  S& w% V6 x6 A, w     缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。
& f4 [" B8 h! h) ]( |

8 t5 E5 w5 O, ~) g; q8 D3 M& U   
, O2 p8 u' \& Z相關資料:
) c( T$ v% f/ ^http://www.synology.com.tw/cht/index.php
  y$ V; j2 J- U- {; ?http://www.eglibc.org/home
http://www.gnu.org/software/libc/
3 N6 t+ U3 `) mhttp://www.uclibc.org/
3 N# d. ~) E: |$ I, w, B6 |) A
[ 本帖最後由 jacky002 於 2008-1-28 10:21 PM 編輯 ]