|
這篇是版主前陣子所寫的一篇文章,如果各位網友有其他的獨特見解與看法,歡迎一起加入來討論。5 ]% ?# }9 Y, s6 {- Y6 A9 C
4 ]) j0 N* |+ T' t- V5 C6 @
在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。4 X. i Q" p0 D9 ^: ]" ~
為了要解決此類的問題 , 一般會有以下幾種作法:
# ~3 h9 u! U6 T' Z) R) P1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。
. }( z, v* w4 Y1 q+ x# w, G2 O9 j 此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.
7 Q: ~) q7 N. h* x% d$ f/ G3 ]& R, j ! C* I0 ~7 c2 t5 C
2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
5 ?! d* S. e2 H5 h, P; i/ F 以下介紹三種不同的 C Library
4 Q7 |; _. r5 ^( I+ B GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用, N# ?7 T5 d) O9 T4 {
Pros: 函式庫支援最多而且沒有相容性問題 D* h- C& B4 D$ w; U3 e r9 B
Cons: 編譯出來的footprinte過大 不適用於產品量產化
) v' L% J0 R2 T4 M, c# X0 N7 J# Q( M' _
& \4 @4 l: L8 C) j/ v uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。
% g5 I0 T( N- W9 R$ e1 U Pros: 編譯出來的footprint很小 最適用於產品量產化
' m6 h* H: e& }3 B7 \6 U Cons: 函式庫支援較少而且會有相容性問題( R! e: b* K5 Z: i
) i* b0 z" F& n/ z3 @
EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善
# o& D$ m" h O1 h. } Pros: 函式庫支援最多而且沒有相容性問題
: I" B P! J, F5 ?9 _2 [ Cons: 編譯出來的footprinte過大 不適用於產品量產化 + m0 n- B* J2 z) f I# P" h
& p- d6 Z9 m; y5 l% U, v9 g 基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:
; _; P# O: h4 Z L4 C& W+ L) w& \ Footprint size(由大到小): GLibc > EGLib > uCLibc! g3 d* g. b: i4 S! g( g5 t$ O. n; I
Compatibility (由最佳到次之): GLibc = EGLib > uCLibc6 G9 T9 a( l6 w: N1 C
; Y. t& q$ t4 B" _* i2 L7 [3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。/ U1 `8 [" R% X1 T) \; d" G( l/ J
- 靜態連結 (Static link) vs.動態連結(Dynamic Link)
9 g0 b& y8 {/ q, g0 K" U( D8 M Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link)/ e% r$ z& o6 n8 p* g Z
Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link). V6 G: B' Z# v! t
取決於所需與目的所在.
/ m% x. c }& N, d3 h 8 H! F5 Q2 ]/ v/ X ^6 T6 v; ]) H# P
- 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.
`) J# {9 u8 A0 g$ A# x
# I* Z+ N2 N/ k) p - 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint
% c* N; J; P0 `- G, S8 \8 { * \3 }. E' s, W4 h3 P! b7 z
- 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk./ |$ D2 {2 x# V& C
Pros: 減少footprint size
0 c+ ^% J5 M" M' Q Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間
( f6 Y( c/ O8 s* T! ^ {
/ j3 l, y* w1 q+ S( j0 S 折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行.
! h6 k+ j! A/ h$ Q$ J 缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。
# [$ S" @( ~0 [! F$ \( B
5 N- e- N/ _. V. }6 a2 x9 i
$ n0 M8 ^' H1 w+ d; D% g
& a3 p- \0 U( L& Y3 ~* |: E# E4 c% a相關資料: E; I c$ T& K2 I' w, V
http://www.synology.com.tw/cht/index.php
/ u! i- u/ J* A/ ihttp://www.eglibc.org/home
' o2 C) ?! H. R. i* x* I5 D! khttp://www.gnu.org/software/libc/
' U7 n( u! O% O: S* t8 r* ahttp://www.uclibc.org/
" I& ]0 B* ^/ Q. G0 H ~" v( c' `' Q/ r
[ 本帖最後由 jacky002 於 2008-1-28 10:21 PM 編輯 ] |
|