|
這篇是版主前陣子所寫的一篇文章,如果各位網友有其他的獨特見解與看法,歡迎一起加入來討論。
9 `7 e. N4 N8 Z& R; A/ K0 _& h, v) ~5 C0 g' J$ F. p
在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。
4 ]' [( c- r6 @2 s2 N- l為了要解決此類的問題 , 一般會有以下幾種作法:9 P% ~0 I0 ?' q2 t6 P# }& `" w
1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。& \9 A1 t# U3 M1 q3 r
此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.* s9 D3 G( A5 @% l$ T
# ^" F$ I# K: M
2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
3 h6 F; y+ A- o4 L 以下介紹三種不同的 C Library# P; T( Q4 j0 @. K- B- O1 f
GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用) Q' M; F' x2 Z# j; y; j
Pros: 函式庫支援最多而且沒有相容性問題
7 o" s1 I; d1 @+ J, Z p } Cons: 編譯出來的footprinte過大 不適用於產品量產化# H' t3 ]" x/ u$ \: Z/ C
! F& v' K* k) t, g' [5 o0 [+ C
uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。
, G9 v/ n9 v( x( L2 a Pros: 編譯出來的footprint很小 最適用於產品量產化
) l9 k3 d) A& N1 u8 i7 h Cons: 函式庫支援較少而且會有相容性問題4 V) q+ E; j6 n0 J& J
* ?- y; D/ x! x EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善7 G" X' ?; `+ E: G/ P
Pros: 函式庫支援最多而且沒有相容性問題
. ~# k( A9 }& Y ~$ @ Cons: 編譯出來的footprinte過大 不適用於產品量產化
& \9 X, H6 H4 D; o3 u, t! }1 B6 C
2 p# [" ]4 S5 v7 s4 G 基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:, T1 T% q- i: {' ~/ Q' M( f9 B
Footprint size(由大到小): GLibc > EGLib > uCLibc0 u) O( v( v B4 J" \; X3 z( H
Compatibility (由最佳到次之): GLibc = EGLib > uCLibc
( v9 v0 O. j2 q$ z* M
* s1 P, }/ r( R3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。
: T$ ]9 f. i9 h# Q" g - 靜態連結 (Static link) vs.動態連結(Dynamic Link)( A5 C' o; M0 W: t+ e2 z9 B7 h- ~9 T
Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link)
. ]; m* ^0 s( p0 q+ W3 C Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link), d9 l. k3 |' B
取決於所需與目的所在.
- {+ q6 y% W) \ y9 G# W
: S. ~0 V, y1 F0 z' T - 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.
, O% o8 z* q8 P
- n( }& G( q: r7 x - 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint1 S+ P, J. i7 L8 ?# g
. ^2 u y5 E7 Y( S& i4 e
- 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk.
# G$ b% e8 c4 L7 g" @ Pros: 減少footprint size
9 r1 F% k* e N0 K" z; g! ]5 t" L Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間 r( H0 U& i5 P2 \
|* D: R8 V+ U) L
折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行. * ?; ^5 V: t* E) J
缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。
8 S# C& l+ e }1 q
" o! k/ P+ D3 W3 `! S
; g& Z& s: K6 p$ E - K/ y7 H/ U" `3 a! v5 u F
相關資料:% M5 y$ C8 y7 L! B* A2 Y* ~- U
http://www.synology.com.tw/cht/index.php
/ S5 b2 Y9 N, z. m: ohttp://www.eglibc.org/home
; f m- ^$ t6 rhttp://www.gnu.org/software/libc/5 W1 p D) C1 @8 x& c1 d7 a
http://www.uclibc.org/% C9 Q* K" v. Q3 ~: [* o$ V# A
" E% R, x4 k2 D4 k+ ?5 P; [[ 本帖最後由 jacky002 於 2008-1-28 10:21 PM 編輯 ] |
|