一種支持I/O的核外中斷執行算法
加入技術交流群
實現核外中斷實際上包含三個步驟：
(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的實現應該是可以接受的。
評論