摘   要： 通過對嵌入式實時操作系統ARTs-OS的研究，借鑒各種實時系統的中斷實現技術，提出了一種支持I/O的核外中斷執行算法。
關鍵詞： 微內核  嵌入式實時操作系統  核外中斷

　　ARTs-OS是一個基于微內核的嵌入式實時操作系統。ARTs-OS中的中斷管理應該提供的基本功能包括：管理中斷處理設備、中斷服務例程的管理、中斷嵌套的管理、中斷棧的維護、線程/進程切換時的現場保護和恢復等。但是ARTs-OS作為嵌入式實時操作系統，上述基本功能不能滿足所有的要求，它還必須擁有更多體現嵌入和實時特性的功能。ARTs-OS在實現中必須采取一些措施將中斷分配時間（IDT）和中斷服務時間（IST）減到最小，并使用戶能夠很容易地在ARTs-OS上開發、調試驅動程序。
1  ARTs-OS的I/O特點
　　ARTs-OS的I/O體系結構的主要特點有：(1)基于微內核構架。(2)支持動態加載。(3)核內/核外驅動。(4)進程/線程模型。(5)中斷硬連接。
　　中斷管理對I/O的支持由I/O的設計方式決定，集中體現在核內中斷管理和核外中斷管理。本文集中討論核外中斷管理。
2  ARTs-OS的核外中斷
　　所有的操作系統都實現了核內驅動，并且核內驅動對中斷管理的要求相對簡單。ARTs-OS的中斷管理在這一部分只簡單地提供一些函數調用。下面重點介紹核外驅動。
　　ARTs-OS中斷管理只需提供核外硬中斷機制便可實現對核外驅動的支持，即提供如下的功能：當硬件產生中斷時，系統核心保存現場，然后跳轉到核外驅動程序ISR并執行；執行完后，恢復現場重新回到核內。整個過程如同核外驅動程序的ISR在核內運行。
　　要實現這個過程需要明確以下幾點：
　　(1)系統如何從核心跳轉到核外的驅動程序ISR。若該ISR的代碼段在核內，由于處于同一個保護層次中，則可以直接調用。但若驅動在核外，一般系統的保護機制是不允許這樣調用的。
　　(2)驅動程序ISR執行完畢后，跳轉到何處。比較好的方法是：返回到系統內核ISR調用驅動程序ISR的地方，但實現起來比較困難。因為一般的過程調用是通過CALL和RETURN指令以及返回地址的堆棧保存這種“過程調用/返回”協議自動地返回到調用點(的下一條指令)。然而，當驅動程序在核外時，它們使用的根本就不是同一個堆棧，核內ISR使用0層堆棧，核外驅動ISR使用被中斷應用程序的地址空間中的3層堆棧。如何實現這種切換返回需要仔細考慮。
　　(3)如何處理驅動程序ISR對驅動程序中全局變量(例如：驅動程序緩沖區)的訪問。一般函數中不存在這樣的問題，但在驅動程序ISR中，這將成為一個很重要的問題。一般的函數是由該函數所在地址空間的其他函數所調用，當執行到該指令時，CPU的進程/線程調度機制已經將該進程的地址空間恢復，普通函數根本就不知道進程的地址空間在CPU上被不斷切換這一事實。但對于中斷響應函數ISR就不是這樣。驅動ISR是由操作系統內核(具體為：內核的中斷ISR)調用，而內核中斷ISR被調用的時機與操作系統自身的運行是異步的，也就是說，在任何時候都有可能發生硬件中斷。因此，有可能在另外一個應用程序運行時發生硬件中斷，從而調用驅動程序ISR。如果不進行特別的處理，驅動程序ISR訪問的全局變量將是另外一個應用程序空間中的地址。
　　為了解決以上問題，ARTs-OS使用了一種與UNIX系統實現信號[1]類似的方法。采用這種方法的一個前提條件是核外驅動程序必須常駐內存。道理很簡單：中斷隨時可能發生，如果核外驅動程序不在內存而是在硬盤中，要執行驅動程序的中斷服務例程就必須將驅動程序加載到內存中，這非常耗時；同時因為中斷服務例程執行時系統的特殊狀態，這個加載過程是難于實現的。所以ARTs-OS假定所有的核外驅動程序都常駐內存。作為一個嵌入式實時系統，ARTs-OS本來就要求程序能夠常駐內存，所以這樣的假設是成立的。
　　ARTs-OS采用的算法和一般的程序調用方法類似。而要實現在核內核外之間的跳轉，系統必須保存和恢復必要的信息。這些信息包括：內核的當前上下文環境、核外驅動程序的上下文環境。
　　執行核外中斷程序的算法如下：
　　輸入：中斷號iid，線程號tid
　　輸出：無
　　步驟：
　　(1)根據iid和tid得到中斷程序的地址。
　　(2)在內核中保存信息以便中斷程序執行完畢后返回。
　　(3)在tid對應的線程堆棧中寫入返回到核內的代碼。
　　(4)跳到線程的中斷函數執行。
　　(5)使用剛才寫入的代碼跳回內核。
　　(6)使用在內核中保存的信息，恢復內核的上下文環境。
3  用戶態掛接中斷的實現
　　實現核外中斷實際上包含三個步驟：
　　(1)跳到核外中斷處理程序。在IA32平臺下，由于CALL/JMP類指令有保護機制的約束，只能由外向內跳轉，而RET和IRET指令恰好相反，只能由內向外跳。因此，一個很常用的技術的就是采用RET或IRET指令實現由內向外的“調用”。首先在堆棧上壓入需要調用的核外驅動ISR代碼的首地址CS：IP及相應堆棧的地址SS：ESP。在保護模式下，CS為用戶代碼的段選擇子，SS為用戶堆棧的段選擇子。執行RET或IRET，硬件將從堆棧上彈出CS：IP和SS：ESP。CPU進行安全檢查之后，就可以執行ISR。ARTs-OS使用IRET指令完成此功能。
　　(2)從核外驅動返回內核。核外驅動ISR執行完后，要返回到內核ISR的調用處。因為IA32平臺的限制不能采用常規的返回執行，所以應采用“堆棧執行”的技巧。即在堆棧上壓入匯編代碼，然后利用返回指令執行該代碼，實現重返內核。具體步驟：①調用驅動ISR之前，應作一定準備工作；②保存內核的當前運行狀態；③找到核外驅動程序ISR將使用的堆棧；④在堆棧中壓入代碼，該代碼主要實現INT n的系統調用，重返內核，該堆棧中還包括用于平衡堆棧的代碼；⑤將代碼的首地址壓入堆棧，作為返回地址；⑥建立好過程調用的“調用幀”的前半段后，用IRET指令進入該驅動程序ISR；⑦進入內核后，根據以前保存的信息恢復到內核以前的狀態。
　　當執行到驅動程序ISR的RET語句時(該RET編譯后為一個段內近調用，因為編譯器并不知道該函數會被系統“回調”，所以把它當作一個普通的函數進行編譯)，由于返回地址為堆棧上事先壓入代碼的首地址，所以執行該代碼；在平衡堆棧后，用INT指令重返內核。
　　(3)驅動程序地址空間的恢復。為了方便驅動程序ISR訪問驅動程序空間中的全局變量，應當在進入核外驅動ISR之前恢復該驅動程序的地址空間。這類似于進程切換。首先將該驅動程序強制性切換到運行態，即恢復其寄存器上下文環境等，然后執行其中的ISR。
　　在這個過程中要用到描述一個用戶態中斷的數據結構，用C語言表示為：
　　typedef struct UserInterrupt_t{
　　ThreadId id；//表示注冊此中斷的線程id
　　unsigned long interruptId；//惟一表示一個中斷
　　InterruptFunction function；//中斷的服務函數指針
　　unsigned long parameter；//中斷服務程序使用的參數
　　struct UserInterrupt_t *next；//用來維護一個鏈表
　　} UserInterrupt，*UserInterruptPtr；
　　實現中斷掛接的主要系統調用：
　　SyscallError tmAttachInterrupt(unsigned char irqno，InterruptFunction function，unsigned
long parameter，unsigned long *intId)；
　　SyscallError tmDetachInterrupt(unsigned long intId)；
　　實際上，因為IA32平臺的限制，用戶態線程/進程不能直接操縱I/O。為了更好地實現核外驅動，中斷管理模塊還提供了一個關閉這種限制的函數：
　　SyscallError tmIOPL(unsigned char on)；
4  核外中斷的評價
　　ARTs-OS的核外硬中斷可以滿足I/O管理的要求，它具有下列優點：
　　(1)實現簡單。ARTs-OS的核外硬中斷實現起來非常簡單，內核只需額外提供幾個系統調用。而這些系統調用的實現方法也很簡單，且結構清晰、所需的代碼少，完全能夠滿足ARTs-OS作為嵌入式系統的需要。
　　(2)驅動程序編寫簡單。中斷管理為核外驅動程序提供幾個系統調用，如：掛接中斷、刪除中斷等。驅動程序只需準備好相應的中斷處理函數調用系統調用即可。驅動程序使用核外驅動和使用其他系統調用一樣簡單，無需特殊的操作。
　　(3)調試方便。通常，驅動程序在核內運行，其中斷服務程序也在核內運行。一般的調試工具不能調試核內的程序，ARTs-OS則不同。因為核外中斷的中斷服務程序是核外的函數，這些函數使用的數據、函數都在核外，所以核外中斷的中斷服務程序和運行在核外的其他函數沒有本質的區別，便于使用GDB等調試工具。
　　但是核外硬中斷方法也有不足之處，例如運行效率較低。因為中斷服務程序在核外運行，每當中斷到達時，為了執行相應的中斷服務程序必須到核外，執行完畢后又必須切換回核內。這樣執行每個中斷服務程序都必須來回進行上下文切換，從而導致運行速率下降。實際上，ARTs-OS針對這種來回切換的情況進行了一些優化，切換時只需保護和恢復必須的上下文，這樣的速率延遲還是可以接受的。另外，核外中斷方法還會對系統的安全性產生一定的影響，因為驅動程序能夠使用核外的驅動方式，必然導致運行在核外的驅動程序擁有一些特權。但實際上這種安全性的保障應該是驅動程序編制者的任務，即驅動程序編制者應該自己保障其中斷服務程序不破壞系統的安全性。
　　綜合考慮系統的擴展性、簡潔性和功能，ARTs-OS的實現應該是可以接受的。
參考文獻
1   Buhr P A，Mok W Y R.Advanced Exception Handling   Mechanisms.IEEE Transactions on Software Engineering，2000；26(9)
2   Intel Corporation.Order Number 245470-012.The IA-32  Intel architecture Software Developer′s Manual Volume 1：Basic Architecture.1999：47~263
3   Intel Corporation.Order Number 245471-012.The IA-32  Intel architecture Software Developer′s Manual Volume 2：Instruction Set Reference.1999：41~765
4   Intel Corporation.Order Number 245472-012.The IA-32  Intel architecture Software Developer′s Manual Volume 3：System Programming.1999：31~443