這種方法在同一硬件平臺上采用了兩個相互配合，共同工作的系統核心，一個核心提供精確的實時多任務管理，另一個核心提供復雜的非實時通用功能。

　　這種方法是通過在Linux操作系統的最底層增加一層實時核心層來實現的。實時核心負責硬件管理并提供實時任務管理。實時核心還用軟件“模擬”常規Linux系統對底層硬件的使用/禁止中斷，而不是真正的操作中斷控制寄存器。Linux核心被看做實時核心中優先級最低的任務來調度，只有當沒有可運行的實時任務時Linux核心才被調度。

　　這種方法的一個關鍵所在是運行在常規Linux核心上的所有非實時任務必須是支持可搶占式調度的。這樣才能做到對實時核心提供精確實時保證沒有任何影響。由于實時核心非常小，并不會增加整個系統的負載，所有這些對開發實時性要求嚴格的實時軟件都提供了有力保障。

　　這種方法的弊端在于實時任務的開發是直接面向提供精確實時服務的小實時核心的，而不是功能強大的常規Linux核心。因此，實時任務是運行在系統核心層的，這就意味著這些實時任務可以運行在沒有內存保護的級別之上。所以，一個實時任務的錯誤可能會導致整個系統的癱瘓!更要命的是，這些實時任務的開發由于面對的是小的實時核心，而不能直接利用Linux API和第三方軟件及運行庫。

　　這種開發模式暗示我們必須要對應用進行靜態分解。把它分解成實時部分和非實時部分。在大多情況下，這是件好事情。它迫使開發人員將應用系統分解成實時子系統和非實時子系統兩部分。但很顯然，使用這種開發模式也限制了應用的類型!因為，這種用二元論觀點看待實時系統的方法并不適合所有的應用。在一些應用中，實時部分和非實時部分的界線并不是十分分明，期間可能存在著不同程度的軟實時部分。

　　這種方法的另一個不足之處是，開發模式混合了實時應用的兩個不相干維度――功能需求和實時需求。它要求應用的實時需求必須限制于由實時核心提供的功能需求限度以內。而實時核心提供的功能支持非常有限。當然我們也可以擴展實時核心的功能，比如增加實時網絡功能等。然而，新增加的部分很有可能會重疊Linux核心已有功能，而導致了不必要的系統“膨脹”，并折損這種方法的價值。 修改核方法

　　這種方法是基于已有Linux系統對實時軟件開發的支持，進行源代碼級修改而使Linux變成一個真正的實時操作系統。這種方法也是和Linux哲學相吻合的。任何基于Linux核心源代碼修改的產品，都要遵循GPL 協議，對所有軟件人員開放源代碼。一旦很多人認為它是有用的，就會有人對它進行維護，或者是混合在通用Linux核心中，或者是單獨分出一個實時Linux分支。

　　這種方法的中心原則是精心選擇部分改動，就可以滿足一系列相關Linux實時開發。此外，由于這些改動都是相對局部的，不會從根本上改變Linux的核心。而且一些改動還可以通過常規Linux的可加載模塊方式完成。在需要時系統可以動態加載該功能模塊，在不需要時還可以動態卸載該模塊。

　　比如，修改之一是核心搶占式調度。把核心從非搶占式變成搶占式是結構上的大變動，并可能引起很多問題，但很多問題已經在Linux支持SMP 的時候解決了。因此，核心的搶占式修改就可以簡單地利用SMP 掛鉤。另一個修改點是前面提到過的使中斷處理句柄可調度。還有一些修改是全局的，例如修改系統時鐘服務來提供更高精度的“心跳”，而不增加不必要的系統負載，或者是提供在核心實現互斥機制來支持優先級繼承。

　　資源核方法

　　這種方法是為解決傳統實時操作系統中固定優先級搶占式調度策略的局限性而產生的。固定優先級搶占式調度算法沒有任務間的臨時保護。因此，可預見的任務響應時間依賴于對所有更高優先級任務執行時間的預測。在這樣的系統中，可預見性是與全局相關的，并且可能被一個糟糕任務而影響的。此外，這種用靜態觀點看待實時系統也是不妥的。在很多實時應用中，更希望實時系統可以根據應用程序獲得資源動態地調整任務屬性，以求得到最優效果。

　　資源核方法是一種以資源為中心來指導實時核心提供精確的、有保證的、可搶占的獲取系統資源的方法。只要實時應用所需資源可以由核心后臺資源管理程序調配滿足，實時核心是允許實時應用可配置的。因此，實時核心其實是提供了實時應用可構建的基礎――從配置簡單的實時系統到復雜的實時系統，都可以通過動態地改變實時任務屬性和它們在整個系統中的優先級來滿足。

　　這種方法的最大優點是系統具有很好的健壯性、可精確預見的實時性。另一個優點是允許應用程序根據實際情況動態調整自身屬性。此外，這種方法非常適合嵌入式系統的開發。