|
這篇是版主前陣子所寫的一篇文章,如果各位網友有其他的獨特見解與看法,歡迎一起加入來討論。
) l2 ` ]$ _% o& B* Q* U, F; Z! f4 P+ g; [# D! g
在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。+ e6 G+ O$ i5 N0 O4 O
為了要解決此類的問題 , 一般會有以下幾種作法:
& z3 f9 y U" F9 t% x$ O; h* T1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。
8 `* G& ?! N- t6 z5 o) S 此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.
( ~' q7 ? I& |4 S
# d$ C$ Y$ d* {3 u2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
. b% q( H( M: H0 N) q 以下介紹三種不同的 C Library
" D. z W0 n" L. A. j GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用
) ?' o# f- M! d$ Y Pros: 函式庫支援最多而且沒有相容性問題
5 h3 |5 ?3 t" D. ` Cons: 編譯出來的footprinte過大 不適用於產品量產化$ U) [- ~) K0 ~
|5 t8 S: V+ y! K. j
uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。, t) c. g( `3 [+ f
Pros: 編譯出來的footprint很小 最適用於產品量產化
3 j/ t) i. d- Q Cons: 函式庫支援較少而且會有相容性問題. v' F* W5 \+ e3 h8 e8 h
O! d% S: ?7 |7 a" f EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善. z( g9 r0 e, l- N$ D, A# P
Pros: 函式庫支援最多而且沒有相容性問題 t1 g1 v( W& U/ d
Cons: 編譯出來的footprinte過大 不適用於產品量產化
7 M7 m" @9 d3 F+ n9 ] , q* z$ L8 {. O* Z
基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:) P% h3 Y! j# l% u P
Footprint size(由大到小): GLibc > EGLib > uCLibc2 V" D/ h9 V+ X' @$ N
Compatibility (由最佳到次之): GLibc = EGLib > uCLibc* U: R8 o6 T! L) H+ ?
" C; r! P8 k* }0 t
3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。! ^; C" v, y+ R
- 靜態連結 (Static link) vs.動態連結(Dynamic Link). b1 ^+ p! ^) L P! b% T" k* E& {
Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link)
) t6 ?9 ?* O+ W. Y Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link)$ [! v. l# I7 S( P, Z: r3 U
取決於所需與目的所在." B- w0 B3 [5 z7 Q6 U
" @' n% q. l0 g
- 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.1 V, O: a$ n/ Y. o! p7 i
* R7 ~9 @7 q& D
- 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint
+ G1 q1 k: N$ x7 a* t0 r2 p! `
) w9 q& _7 X& f' e, b7 a4 T - 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk.
7 ~0 D& o1 W, a' A; W/ F Pros: 減少footprint size
. a0 U5 i4 z7 z! O) I% E Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間# T, c& T5 S' p2 n( _2 a9 y
4 z7 t0 l& s6 Y5 K4 Y' t8 X 折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行.
1 Y- F; Z: f }2 f& \8 V 缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。 ?! E2 n' _% W6 [8 |( W
/ t! N5 S# H% p
( K) w3 a+ x% y+ x 5 O$ c; S) u3 K
相關資料:
- ?3 V7 |' t. h/ h5 L% K6 ghttp://www.synology.com.tw/cht/index.php
, G, O/ v/ q% J/ Phttp://www.eglibc.org/home
# r- k& P4 O$ `+ qhttp://www.gnu.org/software/libc/
" V( I4 @6 B9 h: l& Ehttp://www.uclibc.org/
* ~% F9 _2 Z- b" G
) g' b! v* c+ ?8 t5 e3 I[ 本帖最後由 jacky002 於 2008-1-28 10:21 PM 編輯 ] |
|