(出處: 大黑狗偉大航道之航海 )
菜鳥：『可不可以再提一個比較”高階”的例子，畢竟我們現在用的是32bit的CPU，而且似乎也沒可憐到需要為了幾個byte斤斤計較。』
PM：『OK，我來講一個跟embedded Linux有關的案子；這個內部的案子我之前應該有跟你提過，希望將原本在RTOS上已開發好的應用移植到embedded Linux上；
再繼續討論下去之前，這種案子有幾個重要的背景需要先知道：
1. Embedded Linux會用在比較高階的產品線，但採用embedded Linux的產品仍必須具有原RTOS系統上的所有應用(例如可上網的多媒體播放器，雖然新增了網路應用，但絕對不能忽略了多媒體播放功能。)
2. 使用RTOS的低階產品仍有市場需求，亦即應用程式仍可能繼續發展與改善；而所有應用程式的改變都必須能反應到使用embedded Linux的高階產品線。簡單的說，我們希望使用RTOS與embedded Linux的系統，可以共用同一套應用程式的source code。
3. 高階產品(採用Embedded Linux)新增功能，影響不要到既有RTOS上的應用程式。
4. 無論專案採用RTOS或embedded Linux，系統必須能夠執行在同樣的硬體架構之上；但RTOS與Linux驅動程式的寫法是截然不同的。
因為要考量的事情真的很多，大家往往很容易一不小心就鑽入技術細節的黑洞中，而這就是設計系統架構的大忌 – 骨架沒出來，任何對骨/肉的討論都沒太大意義！而且我們上面說過，系統架構設計本來就是一種循序漸進過程。
當我參與這個專案的討論之後，我實在受不了這種冗長又無法產生結論的會議；雖然不是由我主導這個專案，我還是畫了幾張架構圖，雖然不會是最後的方案，但總算把大家拉回系統架構設計的正軌上。
一旦我們認真檢視這個專案真正的目的，你會發現一開始就把重心放在embedded Linux是不對的…』
菜 鳥：『沒錯，工程師個性就是如此，總是傾向於花時間與注意力在自己沒作過的事情上。Porting Linux到既有硬體平台上只是這個專案的主要工作之一而已，這個專案主要的目的其實是要找出一個可以讓embedded Linux能共用RTOS上既有應用程式的方式罷了。』
PM：『沒錯，很多事情都是當局者迷，旁觀者清。既然目標是共用RTOS上的應用程式，我們當然得先來看看既有的系統架構，是個很嚴謹的分層架構。』
圖6-29：既有產品線，使用RTOS當核心的系統架構
PM：『這是一個典型的基於RTOS的multi-tasking system，我們來檢視一下，這個系統中哪些模組是可以與Linux共用的？』
菜鳥：『Linux本身就是一個完整的系統，有自己的驅動程式、記憶體管理、標準C函式支援…等，此外還有許多專為嵌入式系統所設計的GUI系統可選擇，例如：QT/Embedded、Micro-Win…等等。
從上圖看來，我認為OS-API以下乃屬於系統部份，RTOS與embedded Linux並無法共用這些系統模組。而設計OS-API的目的就是希望OS-API以上的程式模組是OS-independent的，亦即上層程式只能透過呼叫OS-API來使用系統與硬體功能；所以理論上只要在embedded Linux上包裝出完全相同(介面相同 ＋ 行為相同)的OS-API，並使用embedded Linux上的thread模擬原先RTOS上的task，則原RTOS上的middleware與application應該就能再Linux上跑了吧。』
PM：『不錯，分析得很好，越來越有sense了；所以我們畫出的系統架構圖如下：』
圖6-30：RTOS與Linux共用middleware與application的系統架構
PM：『上面這張圖以OS-API作為區隔，往上是與OS無關的部份，也就是我們希望RTOS與embedded Linux能共用的模組；往下分為兩部份，左邊是RTOS，右邊是embedded Linux，後者為了要包裝出既定的OS-API，勢必要額外補上一些功能。
這張圖中值得一提的是HAL(Hardware Abstraction Layer/硬體抽象層 )；驅動程式的穩定度是整個產品品質的根基，所以我們希望兩個系統能最大程度地共用驅動程式，為此我們定義了硬體抽象層API。也就是說，無論硬體配置是否相同，驅動程式都必須包裝出通同的介面(HAL)，系統(RTOS or embedded Linux)則將HAL當作是抽象的硬體，再依該系統的規範實作驅動程式。
所以即便RTOS與embedded Linux上對驅動程式的寫法有不同的規範，在我們的系統架構中，真正”驅動”硬體的程式則只有一套，這可以為以後的測試與品質工作省下很多麻煩。
言歸正傳，當我們有了兩個系統共存的架構圖後，我們可以依此畫出embedded Linux執行原RTOS上之application的架構圖；其實就是把上個圖中RTOS的部份去掉，再加上embedded Linux上為了要包裝出OS-API所需額外補上的模組即可。請參考下圖：』
圖6-31：以Linux當核心，執行原RTOS系統上的所有功能
PM：『這張圖應該很容易理解，在此我就不解釋了。看圖說故事是最好的溝通方式，至此共三張圖應該可以把故事說清楚了。當然不是系統架構圖出來後就天下太平 了，這只是初稿而已，但至少所有人有了可以討論的平台；而且在接下來的討論中，我們會再擴充或改良系統架構圖，讓所有人都可以從這些圖中了解，我們到底要把這個專案作成什麼樣子？
舉例來說，老闆看了以上三張圖後似懂非懂的問道：”這些圖說明了兩個系統如何共用application，那如果embedded Linux想要擴充功能，如何保證不會影響既有的application？”，則我們會發現少了一張圖說明embedded Linux上既有application與擴充功能如何共存；當碰到這種情況時，立即補上就是了，我們不是一再強調系統架構設計是一種循序漸進的過程嗎？沒有人有把握將新專案的系統架構一次就設計完整無誤的。』