|
這篇是版主前陣子所寫的一篇文章,如果各位網友有其他的獨特見解與看法,歡迎一起加入來討論。
8 s) a/ N. y$ B; K$ K3 a& a* m0 b- r, N: T
在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。' h8 W3 _% A2 q% Z7 j# E
為了要解決此類的問題 , 一般會有以下幾種作法:
# M( C4 I% m5 Z1 z1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。
' d- d6 e W& l 此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.8 `! L! `' T2 F/ P6 O
6 E4 Q1 m6 W; O4 Z1 n a7 S
2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
% ^ a: Q J0 g0 m9 g$ Q6 U3 h. Y 以下介紹三種不同的 C Library
% s2 n2 E3 K& S3 C; X% T' z' d# I GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用
( v# J1 U+ e" w6 l0 k6 Q, D Pros: 函式庫支援最多而且沒有相容性問題( U1 [9 Q, H6 z
Cons: 編譯出來的footprinte過大 不適用於產品量產化% H% H* W0 D* o! C! d) V
! x* u# M- G2 F. V" O0 ^
uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。# F0 y# [9 X0 R1 O$ y/ |, e
Pros: 編譯出來的footprint很小 最適用於產品量產化: N/ |. y' [( M2 `2 ?$ |" ^/ C
Cons: 函式庫支援較少而且會有相容性問題% u. m% b }$ E5 }% q0 K
- X# Y7 L. Y) j EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善4 p! L! c' a. A! w. ~' Y4 t) K: T
Pros: 函式庫支援最多而且沒有相容性問題) W0 b i2 L- `( V9 B" m
Cons: 編譯出來的footprinte過大 不適用於產品量產化
# E7 g- T. q7 d
, ?* c, G9 n2 S/ I 基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:$ O7 Z( f* S1 y
Footprint size(由大到小): GLibc > EGLib > uCLibc
1 b( d- H$ L2 i9 ]' ] Compatibility (由最佳到次之): GLibc = EGLib > uCLibc
}1 |' u4 ]; _1 ?) `& [
8 ^) H; [+ u) A2 L7 P. l3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。+ |9 Z K g* s3 @1 K- ~
- 靜態連結 (Static link) vs.動態連結(Dynamic Link)0 d' U, ?7 A9 h/ e" g2 ]" T1 o
Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link)
! E0 E3 \+ W1 P0 C4 r3 N Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link)
$ a# d0 i, y- e3 |5 a' m& n 取決於所需與目的所在.
. u' X2 x# {$ k1 h4 S; t
6 t. E4 [0 X# o P4 _ j - 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.
C0 U9 S- V1 s k* C1 `
Z% K' L6 j, P9 X# X5 h - 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint
8 m) ]9 h$ ^0 H5 x( ]$ I) K- ]& l1 a , d3 L# X& w; O5 B
- 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk.0 G7 Z* F; Y6 s: F6 k2 n, h
Pros: 減少footprint size
+ O: J: c+ [3 y% D4 g1 o Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間$ k" Q! {5 P9 t8 B. ]8 N. a/ e
% J- K0 S7 H7 p) e 折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行.
. E6 b% @/ @2 [: p6 [ 缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。
: ?- L. ?" I8 a$ F$ }/ Y6 x
. v# Q0 \3 ]; H M' z- ^9 V
, o5 i% n7 V1 m
" W# y4 l1 c( T+ q) P5 J# M# ^1 }相關資料:& S2 `5 z# ?/ A: A* ?( a8 K; z
http://www.synology.com.tw/cht/index.php
' z' @: q, d+ ehttp://www.eglibc.org/home
5 D# Z: P( z; f) O& r& thttp://www.gnu.org/software/libc/
) P* K) ~ Z/ chttp://www.uclibc.org/
! b @7 f1 I/ ~& j* d5 G. I+ W0 f( j8 X/ h2 z! j$ C; K6 Y; o6 w
[ 本帖最後由 jacky002 於 2008-1-28 10:21 PM 編輯 ] |
|