作者
李宇
與Linux API的兼容程度是評估這類實時系統的一個重要指標
如果一個實時系統兼容了所有Linux API
那麼就允許所有Linux上的應用程序和庫在其上運行使用
因此
這將會帶來一個巨大的好處
所有在Linux上可用的第三方軟件均可以在其上使用
當然
開發一款這樣兼容所有Linux API的實時系統決不是件容易的事
尤其是對於單個開發商來說
所以
大量的第三方軟件並不能很容易地移植到實時系統中來
這點不足
也使Linux的優勢大打折扣！
雙核方法
這種方法在同一硬件平台上采用了兩個相互配合
共同工作的系統核心
一個核心提供精確的實時多任務管理
另一個核心提供復雜的非實時通用功能
這種方法是通過在Linux操作系統的最底層增加一層實時核心層來實現的
實時核心負責硬件管理並提供實時任務管理
實時核心還用軟件
模擬
常規Linux系統對底層硬件的使用/禁止中斷
而不是真正的操作中斷控制寄存器
Linux核心被看做實時核心中優先級最低的任務來調度
只有當沒有可運行的實時任務時Linux核心才被調度
這種方法的一個關鍵所在是運行在常規Linux核心上的所有非實時任務必須是支持可搶占式調度的
這樣才能做到對實時核心提供精確實時保證沒有任何影響
由於實時核心非常小
並不會增加整個系統的負載
所有這些對開發實時性要求嚴格的實時軟件都提供了有力保障
這種方法的弊端在於實時任務的開發是直接面向提供精確實時服務的小實時核心的
而不是功能強大的常規Linux核心
因此
實時任務是運行在系統核心層的
這就意味著這些實時任務可以運行在沒有內存保護的級別之上
所以
一個實時任務的錯誤可能會導致整個系統的癱瘓！更要命的是
這些實時任務的開發由於面對的是小的實時核心
而不能直接利用Linux API和第三方軟件及運行庫
這種開發模式暗示我們必須要對應用進行靜態分解
把它分解成實時部分和非實時部分
在大多情況下
這是件好事情
它迫使開發人員將應用系統分解成實時子系統和非實時子系統兩部分
但很顯然
使用這種開發模式也限制了應用的類型！因為
這種用二元論觀點看待實時系統的方法並不適合所有的應用
在一些應用中
實時部分和非實時部分的界線並不是十分分明
期間可能存在著不同程度的軟實時部分
這種方法的另一個不足之處是
開發模式混合了實時應用的兩個不相干維度——功能需求和實時需求
它要求應用的實時需求必須限制於由實時核心提供的功能需求限度以內
而實時核心提供的功能支持非常有限
當然我們也可以擴展實時核心的功能
比如增加實時網絡功能等
然而
新增加的部分很有可能會重疊Linux核心已有功能
而導致了不必要的系統
膨脹
並折損這種方法的價值
修改核方法
這種方法是基於已有Linux系統對實時軟件開發的支持
進行源代碼級修改而使Linux變成一個真正的實時操作系統
這種方法也是和Linux哲學相吻合的
任何基於Linux核心源代碼修改的產品
都要遵循GPL 協議
對所有軟件人員開放源代碼
一旦很多人認為它是有用的
就會有人對它進行維護
或者是混合在通用Linux核心中
或者是單獨分出一個實時Linux分支
這種方法的中心原則是精心選擇部分改動
就可以滿足一系列相關Linux實時開發
此外
由於這些改動都是相對局部的
不會從根本上改變Linux的核心
而且一些改動還可以通過常規Linux的可加載模塊方式完成
在需要時系統可以動態加載該功能模塊
在不需要時還可以動態卸載該模塊
比如
修改之一是核心搶占式調度
把核心從非搶占式變成搶占式是結構上的大變動
並可能引起很多問題
但很多問題已經在Linux支持SMP 的時候解決了
因此
核心的搶占式修改就可以簡單地利用SMP 掛鉤
另一個修改點是前面提到過的使中斷處理句柄可調度
還有一些修改是全局的
例如修改系統時鐘服務來提供更高精度的
心跳
而不增加不必要的系統負載
或者是提供在核心實現互斥機制來支持優先級繼承
From:http://tw.wingwit.com/Article/program/Oracle/201311/17179.html
