從零編寫Linux 0.11的系列寫到這一章系統(tǒng)已經能啟動、能進保護模式、能打印字符了。但說實話這時候的內核頂多算個“大號引導程序”——因為CPU還在傻乎乎地按順序執(zhí)行指令。外部設備來了數(shù)據(jù)它不知道定時器走了它不知道連程序自己犯了錯它也來不及反應。中斷機制就是讓這顆CPU從“被動執(zhí)行”變成“主動響應”的那一錘子。寫這一章時我最大的體會是中斷不是操作系統(tǒng)的一個“功能模塊”而是整個內核賴以生存的底層骨架不理解中斷后面講進程調度、內存管理都會像在聽天書。先回顧一個最基礎的問題CPU怎么知道外部有事情發(fā)生答案只有兩條路輪詢和中斷。輪詢是CPU每隔一段時間就問一遍設備“你有事嗎”有事就處理沒事就接著干。這種方式簡單直觀但CPU的大部分時間都浪費在“問”上面而且延遲不確定——設備正好在上一次問完之后來消息CPU得等到下一次輪詢才能知道運氣差一點延遲能被拉得很長。中斷正好反過來設備主動發(fā)一個電信號CPU在每執(zhí)行完一條指令后檢查一下“有沒有中斷請求”有就暫停當前工作跳轉到對應處理程序處理完再回來。這個“檢查”是硬件在指令周期的微操作里完成的開銷極小而且響應是事件驅動的來了就處理不來了CPU安心做自己的事。用人類打個比方輪詢像你每隔十分鐘去門口看快遞到了沒有中斷像給快遞員一個門鈴他到了按一下你再放下手頭的事去開門。門鈴這個機制就是8259A和IDT配合實現(xiàn)的。1.2 中斷向量號從0到255的編號世界CPU能識別的中斷事件不是一個而是256個每個都有一個編號叫中斷向量號。這個256不是拍腦袋定的而是因為IDT最多放256個描述符每個描述符8字節(jié)總共2KB正好是頁大小的整數(shù)倍查表方便。其中0到31號向量是CPU保留的異常由CPU內部觸發(fā)包括除零、缺頁、非法指令等32到255號是外部中斷和軟件中斷。在Linux 0.11里32到47被用作8259A映射過來的硬件中斷號1280x80被用作系統(tǒng)調用軟中斷48到255還空著一大把后面要加什么新功能再分配。這個編號跟你平時說的“中斷號”IRQ0、IRQ1不是一回事中間差了一個偏移量。8259A的IRQ0對應CPU向量號32IRQ1對應33這就是Linux 0.11里init_IRQ要做的“重新映射”工作。如果你不重新映射IRQ0默認對應CPU向量8一進來就會直接撞上Double Fault異常系統(tǒng)當場崩掉。我當初偷懶跳過PIC初始化結果模擬器直接重啟查了半天不知道怎么回事。1.3 保護模式與實模式的分水嶺這一章的標題是“中斷與異?！钡绻豢磳嵞Ｊ奖热鏐IOS階段的中斷那跟裸機編程沒什么區(qū)別中斷向量表放在內存地址0x00000開始處每一項4字節(jié)存的是段地址和偏移查表跳過去完事。但進入保護模式之后一切都變了。實模式的“中斷向量表”變成了“中斷描述符表”表的位置不再固定在0x0而是由IDTR寄存器告訴你它在哪里。每一項不再是一個簡簡單單的地址而是一個8字節(jié)的門描述符——里面不僅有處理程序的地址還包含特權級和類型信息。這意味著CPU在跳轉之前還要做一大堆安全檢查。很多人第一次寫保護模式內核最容易掛在這一點上你在實模式下的中斷能跑進了保護模式一開中斷就重啟十有八九是IDT沒建立或者門描述符的類型/特權級不對。提示CPU在保護模式下每執(zhí)行完一條指令都會檢查“當前有沒有待處理的中斷”。只要中斷允許位IF是1并且IDT里對應向量是有效描述符它就會立刻走中斷流程。所以“開中斷”這件事不是簡單的sti就能完事你得先保證IDT已經就緒。2. IDT一張8字節(jié)一行的查找表2.1 門描述符的位級拆解IDT里的每一項叫門描述符一共8字節(jié)。以Linux 0.11的啟動初始化代碼為例最終要填的是這樣一個結構內存小端序字節(jié)0到1處理函數(shù)偏移地址的低16位字節(jié)2到3段選擇符就是要跳轉到的目標代碼段這里固定填0x0008也就是內核代碼段字節(jié)4這個字節(jié)比較特殊一共8位大部分被用作類型字段的低位在Linux 0.11的寫法里它和字節(jié)5一起構成屬性字節(jié)5P存在位、DPL2位、S1位、Type4位字節(jié)6到7處理函數(shù)偏移地址的高16位一個字一個字拆開看對于中斷門來說Type111014對于陷阱門Type111115。P位必須為1DPL是特權級。內核態(tài)的中斷門DPL0系統(tǒng)調用門DPL3。所以內存里看到的屬性值一般是0x8E00內核中斷門、0x8F00內核陷阱門、0xEF00系統(tǒng)調用陷阱門。Linux 0.11源碼里的set_intr_gate、set_trap_gate、set_system_gate往描述符屬性字段里塞的就是這幾個值。我不厭其煩地把位布局講清楚是因為后面手工寫_set_gate宏時只要任何一個位放錯系統(tǒng)表現(xiàn)都會非常詭異。比如DPL寫成了0你去用戶態(tài)調int 0x80CPU直接判定為特權級違規(guī)扔一個13號異常出來用戶程序根本進不了內核。2.2 中斷門、陷阱門、任務門選哪個CPU一共支持三種門。任務門會觸發(fā)硬件任務切換Linux 0.11基本沒用我們直接跳過中斷門和陷阱門的區(qū)別只有一個細節(jié)進入中斷門時CPU會自動把IF標志清0也就是關中斷防止在處理過程中被新的中斷打斷而陷阱門不會清IF。這個區(qū)別決定了它們的用途。硬件中斷比如時鐘中斷、鍵盤中斷通常用中斷門因為處理過程是高優(yōu)先級的不希望被打擾異常和系統(tǒng)調用通常用陷阱門因為進入內核后我們往往要主動管理中斷狀態(tài)比如缺頁異常處理中你可能希望保持中斷開啟讓磁盤請求完成時能觸發(fā)中斷來喚醒自己。Linux 0.11里trap_init用set_trap_gate注冊異常init_IRQ用set_intr_gate注冊硬件中斷set_system_gate注冊系統(tǒng)調用門各司其職。2.3 lidt只做一件事告訴CPU表在哪IDT準備好以后需要執(zhí)行l(wèi)idt指令把表的位置和大小加載到IDTR寄存器。IDTR一共6字節(jié)低2字節(jié)是表長度減1高4字節(jié)是表的線性地址。在Linux 0.11的head.s里setup_idt這個匯編函數(shù)干的事就是把一整張“空表”鋪好setup_idt: lea ignore_int, %edx movl $0x00080000, %eax movw %dx, %ax movw $0x8E00, %dx lea idt, %edi mov $256, %ecx rp_sidt: movl %eax, (%edi) movl %edx, 4(%edi) addl $8, %edi dec %ecx jne rp_sidt lidt idt_descr ret這段代碼先把256個中斷向量統(tǒng)一指到一個ignore_int函數(shù)——這個函數(shù)暫時什么都不做只在出錯時打一行提示——然后把門類型設成中斷門0x8E00最后加載IDTR。這其實是一種“先把桌子擺好”的啟動策略剛開始來不及逐個設置每個中斷的處理函數(shù)就先拿一個統(tǒng)一入口頂住保證系統(tǒng)不會因為表不存在而崩潰。之后trap_init和init_IRQ再逐個替換成真正的處理函數(shù)。3. 異常CPU主動扔過來的“錯誤報告”3.1 三種異常的語義差異異常跟外部中斷最大的區(qū)別是它不是外部設備發(fā)來的而是CPU在執(zhí)行指令的過程中自己發(fā)現(xiàn)不對勁。比如你寫了一條除數(shù)為0的指令CPU在微碼層面發(fā)現(xiàn)除數(shù)是0就立刻觸發(fā)0號向量你訪問了一個沒有映射的頁就觸發(fā)14號向量。異?？梢苑殖扇怓ault故障、Trap陷阱、Abort終止。用一句話解釋區(qū)別Fault指令“還沒執(zhí)行完”就發(fā)現(xiàn)問題保存的EIP指向觸發(fā)異常的那條指令處理完后CPU會重新執(zhí)行這條指令。頁錯誤就是典型異常處理函數(shù)把缺的頁補上之后回來還能繼續(xù)執(zhí)行。Trap指令“已經執(zhí)行完”了才觸發(fā)保存的EIP指向下一條指令。調試斷點int3就是陷阱處理完直接往下走。Abort發(fā)生了嚴重錯誤程序已經無法繼續(xù)CPU保存的EIP都不保證正確。Double Fault和機器檢查異常屬于這一類。這個區(qū)別直接決定異常處理函數(shù)返回后CPU去哪。如果你想寫一個“屏蔽掉除零錯誤”的實驗型處理程序你必須想清楚你站在Fault的立場上處理完要重新執(zhí)行那條除法指令如果除數(shù)和被除數(shù)沒改你會無限觸發(fā)這個異常。3.2 有錯誤碼和無錯誤碼另一個容易踩的點是不是所有異常壓棧內容都一樣。大部分異常壓入EFLAGS、CS、EIP之后就跳轉到處理函數(shù)了但有少數(shù)異常會再壓入一個錯誤碼告訴你是哪個段、哪個頁惹的禍。這些異常包括10號無效TSS、11號段不存在、12號棧段異常、13號一般保護異常、14號頁異常。這個錯誤碼是硬件自動壓入的但處理函數(shù)返回時CPU并不會自動把錯誤碼彈出去。所以Linux 0.11在處理這些異常時特意把入口分成兩套無錯誤碼的在入口處先壓入一個假的錯誤碼讓后續(xù)C函數(shù)統(tǒng)一按“有一個錯誤碼參數(shù)”來處理有錯誤碼的直接使用“參數(shù)已經由CPU壓棧”的入口。我在寫簡單實驗時曾直接把有錯誤碼的異常和沒錯誤碼的異常當成同一個入口結果處理函數(shù)返回時棧指針對不上iret彈出的是錯誤碼程序直接跑飛。這個問題非常隱蔽你得先把哪些向量帶錯誤碼背下來不然調試到深夜也查不出所以然。3.3 Linux 0.11的traps.c結構Linux 0.11的異常處理代碼有一個“統(tǒng)一處理差異化打印”的好設計。在kernel/traps.c里它給每個異常都注冊了一個入口函數(shù)這些入口函數(shù)最終都會跳轉到一組專門的匯編代碼把現(xiàn)場壓棧然后把“向量號、錯誤碼、當前EIP”作為參數(shù)調C函數(shù)。比如初始化代碼void trap_init(void) { set_trap_gate(0, divide_error); set_trap_gate(1, debug); set_trap_gate(2, nmi); set_trap_gate(3, int3); set_trap_gate(4, overflow); set_trap_gate(5, bounds); set_trap_gate(6, invalid_op); set_trap_gate(7, device_not_available); set_trap_gate(8, double_fault); set_trap_gate(9, coprocessor_segment_overrun); set_trap_gate(10, invalid_TSS); set_trap_gate(11, segment_not_present); set_trap_gate(12, stack_segment); set_trap_gate(13, general_protection); set_trap_gate(14, page_fault); set_trap_gate(15, reserved); set_trap_gate(16, coprocessor_error); }這里的第二個參數(shù)是“入口函數(shù)的地址”但這個入口函數(shù)不是普通的C函數(shù)而是一段匯編。為什么不能用C函數(shù)直接當中斷入口因為C編譯器生成的函數(shù)開頭會有標準的棧布局和現(xiàn)場保存動作但它不會替你把EFLAGS、CS這些由硬件壓棧的值按預期順序彈出來更不會保證處理完后用iret返回。中斷入口必須嚴格遵循“硬件壓棧順序”和“iret彈出順序”所以必須有匯編包一層。這是初寫中斷時最大的思維轉換中斷處理函數(shù)的“調用約定”不是操作系統(tǒng)約定的是CPU硬件約定的。你沒辦法讓編譯器替你遵守這個約定只能手寫。4. 8259A把硬件設備的中斷請求“接線”給CPU4.1 主片從片為什么是級聯(lián)的8259A是可編程中斷控制器俗稱PIC。在PC/AT架構里兩塊8259A級聯(lián)主片管IRQ0到IRQ7從片管IRQ8到IRQ15從片的中斷輸出接到主片的IRQ2上。所以主片IRQ2這條線承載的是“從片有中斷”的信號。這么設計的根本原因很樸實老CPU只有一根INT引腳硬件上無法直接接16個設備只能通過一個控制器匯總。8259A內部有一個優(yōu)先級裁決器多設備同時請求時按優(yōu)先級挑一個報給CPU。你要是不初始化8259A它內部狀態(tài)完全是亂的中斷請求的映射和屏蔽位全不對設備一觸發(fā)就覺得“有扇門倒了”系統(tǒng)立刻崩。4.2 初始化參數(shù)ICW與OCW的計算Linux 0.11的init_8259A函數(shù)寫得很清楚我把關鍵參數(shù)列一下參數(shù)主片從片含義ICW10x110x11需要ICW4、級聯(lián)模式ICW20x200x28中斷向量起始號主片32、從片40ICW30x040x02級聯(lián)關系從片掛在主片IRQ2上ICW40x010x018086模式OCW10xFF0xFF默認全部屏蔽逐個開放主片端口是0x20、0x21從片端口是0xA0、0xA1。為什么要讓主片從32開始因為0到31是CPU異常的保留區(qū)外部中斷必須避開。IRQ0對應向量32IRQ7對應39IRQ8對應40IRQ15對應47后面接設備時看到0x20、0x21這些宏就應該條件反射地想到“這是PIC的口地址不是內存地址”。4.3 時鐘中斷是怎么“開”起來的時鐘中斷是整個操作系統(tǒng)的脈搏。Linux 0.11在init_IRQ里除了初始化8259A還做了兩件事注冊IRQ0的handler以及操作OCW1把IRQ0對應的中斷釋放出來。比如主片掩碼改成0xFE就是把IRQ0開放其他保持屏蔽。注意這里有一個容易混的概念CPU的IF標志是“總閘”PIC的OCW1是“分閘”一個設備要真正觸發(fā)中斷總閘和分閘都得打開。我在實驗里只開了IF但忘了改OCW1結果時鐘中斷永遠不來系統(tǒng)像死了一樣查了很久才意識到PIC側還被屏蔽著。5. 系統(tǒng)調用讓用戶程序主動“敲門”進內核5.1 int 0x80一條特殊指令系統(tǒng)調用是中斷機制最巧妙的用途。用戶態(tài)的程序想訪問硬件、申請內存、打開文件直接執(zhí)行特權指令是會被CPU拒之門外的因為當前特權級是3而特權指令要求特權級0。那怎么辦答案是用戶程序執(zhí)行一條int 0x80指令主動觸發(fā)一個軟件中斷。關鍵點是0x80這個系統(tǒng)調用門描述符的DPL被設成了3。DPL3意味著“處在特權級3的用戶代碼也有權調用這個門”。如果DPL設成0用戶程序一執(zhí)行int 0x80CPU直接判定權限不足觸發(fā)13號一般保護異常。你可以自己動手改一下DPL試試能非常直觀地看到權限檢查在起作用。5.2 system_call的入口匯編邏輯在Linux 0.11里0x80向量指向system_call這個匯編函數(shù)它的執(zhí)行分為三步用SAVE_ALL把用戶態(tài)帶來的所有寄存器壓入內核棧形成pt_regs結構。檢查系統(tǒng)調用號是否越界然后根據(jù)eax里的調用號跳到sys_call_table數(shù)組對應的C函數(shù)。比如eax2就是forkeax4就是write。這里有一個很漂亮的細節(jié)sys_call_table是個函數(shù)指針數(shù)組數(shù)組下標就是調用號所以“根據(jù)調用號分發(fā)”就是一次“數(shù)組索引間接跳轉”。拿到返回值后把返回值寫回內核棧中原來eax保存的位置這樣iret恢復時eax自然就是返回值然后用RESTORE_ALL彈出寄存器執(zhí)行iret回到用戶態(tài)。很多人在理解系統(tǒng)調用時會把它當成普通的“函數(shù)調用”但它的本質是中斷調用用戶程序不壓返回地址CPU壓的是EFLAGS、CS、EIP用戶程序不保證棧方向CPU要切換到內核棧。所以你寫系統(tǒng)調用時不能寫“返回值在eax里”就直接return必須先把現(xiàn)場完整壓棧因為中斷的返回不是ret是iret。5.3 從用戶態(tài)到內核態(tài)的棧切換還有一個繞不開的細節(jié)特權級變了棧也要變。Linux 0.11為每個任務都準備了一個內核棧TSS里有ss0和esp0兩個字段記錄內核棧的段和棧頂。當用戶態(tài)程序觸發(fā)int 0x80時CPU看到當前CPL3而目標代碼段的DPL0立即從當前棧切換到ss0:esp0指向的內核棧然后才壓入EFLAGS、CS、EIP。整個過程由CPU硬件完成不需要操作系統(tǒng)手動干預。用戶態(tài)原本棧里的數(shù)據(jù)并沒有被搬走它們還在用戶棧上CPU壓進去的CS是用戶態(tài)CSss和esp保存在TSS里處理完通過iret彈回。到內核態(tài)之后想訪問用戶棧里的參數(shù)就需要通過用戶空間指針去讀這也是為什么Linux 0.11里很多系統(tǒng)調用函數(shù)要從“用戶棧上取參數(shù)”這一步開始。6. 代碼落地從零初始化IDT的完整記錄6.1 分階段先setup再trap_init再init_IRQ我在實際搭建內核的過程中中斷相關的初始化是分三個時間點進行的這個順序是Linux 0.11源碼給我的啟發(fā)也強烈推薦大家遵循同樣的節(jié)奏第一階段在head.s里setup_idt把256個向量全部指向ignore_int。這一步的目的是先把表建起來但先不處理任何中斷事件。第二階段在main的trap_init里把0到16的CPU異常逐個替換成真正的處理入口。第三階段在init_IRQ里初始化8259A把硬件中斷向量注冊好并打開需要的IRQ屏蔽位。這個順序不能亂。如果上來就讓硬件中斷開著但IDT里沒有對應描述符CPU查表失敗直接引發(fā)Double Fault。先讓PIC全部屏蔽再逐個開放就能把“不知道該誰處理的中斷”扼殺在萌芽里。6.2 _set_gate宏逐行拆解_set_gate是Linux 0.11里最精華的宏之一很多人第一次看到它的內聯(lián)匯編會頭痛。我把它逐行翻譯一下#define _set_gate(gate_addr, type, dpl, addr) \ __asm__(movw %%dx,%%ax\n\t \ movw %0,%%dx\n\t \ movl %%eax,%1\n\t \ movl %%edx,%2\n\t \ : \ : i ((short) (0x8000(dpl13)(type8))), \ o (*((char *) (gate_addr))), \ o (*((char *) (gate_addr)4)), \ d ((char *) (addr)), \ a (0x00080000))編譯器會把d約束里的addr裝進edxa約束里的0x00080000裝進eax。movw %dx, %ax把addr低16位搬到ax這時候eax就變成了0x0008xxxx——前16位是段選擇符0x0008后16位是處理函數(shù)地址的低16位。接著movw %0, %dx把屬性比如0x8E00裝進dx此時edx的高16位仍然是addr的高16位低16位是屬性。最后兩條movl把edx、eax分別寫入門描述符的第0字節(jié)和第4字節(jié)。一個8字節(jié)的門描述符就填好了。寫這個宏的時候我建議初學的人不要光看宏一定要把門描述符的8字節(jié)按“偏移低16位/段選擇符/屬性/偏移高16位”畫個圖對著填充一遍。我當年在紙上畫了不下十遍才真正記住每個bit在哪。6.3 trap_init與init_IRQ的掛接細節(jié)trap_init的代碼前面已經展示過了它調set_trap_gate把0到16的異常入口都設好。這里有個容易被忽略的點2號向量NMI也注冊了。NMI是不可屏蔽中斷不經過8259ACPU的NMI引腳一被拉低就直接觸發(fā)2號向量。Linux 0.11對NMI的處理很佛系打印一條錯誤消息然后進死循環(huán)。因為NMI本身意味著硬件層面嚴重異常普通內核一般不會去“處理”它。init_IRQ做的事是先初始化PIC然后把硬件中斷向量注冊到IDT。注冊時要先把門描述符填好再在PIC里開放對應IRQ順序也是先注冊后開放。我實驗時試過反著來結果中斷先到了處理函數(shù)還沒掛上系統(tǒng)啟動到一半就崩了。這些順序問題在教科書里不會直接告訴你只有跑一遍才知道。7. 實戰(zhàn)復現(xiàn)用一個小demo驗證中斷基礎7.1 先搭一個最小可運行的中斷實驗環(huán)境如果你也正在跟著“從零編寫Linux 0.11”這一系列走我會建議你寫到這一章時不要急著一口氣調完整內核而是先做一個獨立小實驗只保留最精簡的啟動代碼、建立IDT、初始化8259A用一個自定義門來模擬一個“中斷測試”處理函數(shù)里設置一個標志變量并打印一段字符串。如果實驗能在模擬器里跑出預期的打印結果說明IDT、門描述符、特權級鏈路已經通了。直接構造一個最小的測試入口void test_int_entry(void) { printk([test] interrupt handler called!\n); } void test_setup(void) { set_intr_gate(0x40, test_int_entry); __asm__(int $0x40); }如果屏幕上打出了test消息就說明IDT設置、門描述符類型、段選擇符、特權級檢查全都沒問題——這幾個環(huán)節(jié)只要有一步出錯輕則沒反應重則整機重啟。這個小demo比在一整個復雜內核里排查問題要快得多。7.2 用int指令主動觸發(fā)驗證玩過匯編的人都知道int指令后面跟的是向量號int 0x40這種寫法在執(zhí)行時CPU查的是IDT的第0x40項。所以在上述測試里只要把set_intr_gate(0x40, ...)設好然后執(zhí)行int 0x40就能直接跳過外部設備純靠軟件觸發(fā)一次完整的中斷流程。這一步的價值在于如果連軟件觸發(fā)的內部中斷都進不去處理函數(shù)那問題一定出在IDT、門描述符或特權級這部分如果軟件觸發(fā)一切正常但外部設備的中斷沒反應那問題就出在PIC初始化或設備本身。這相當于給整個中斷鏈路做了“單元測試”排查范圍一下子縮小了。我后來調試鍵盤驅動時就是靠這個把IDT的問題和PIC的問題區(qū)分開的。8. 調試心得與避坑清單8.1 Triple fault是怎么發(fā)生的剛連上模擬器跑內核時遇到最多的一個現(xiàn)象是啟動到某一步屏幕上最后一行打印消失了或者模擬器直接黑屏甚至整個模擬機自己重啟。這個現(xiàn)象叫Triple Fault——CPU在處理第一個異常時發(fā)現(xiàn)IDT無效觸發(fā)Double Fault處理Double Fault時IDT還是無效那就無藥可救硬件直接復位重啟。它連顯示錯誤的機會都沒有。最常見的原因有這幾個lidt指令還沒執(zhí)行就開了中斷IDT放在了一個不可訪問的內存區(qū)域或者IDTR的基地址算錯了IDT描述符里的段選擇符指向的段不存在或者特權級不匹配給8259A的初始化命令順序搞錯導致IRQ向量號錯亂。排查Triple fault的辦法是給模擬器打開中斷日志讓它把每次中斷/異常的詳細信息寫進日志文件CPU當前在哪個EIP、觸發(fā)哪個向量、IDT表項內容是什么都一清二楚。我第一次看到日志里滿屏的“check_exception: 8”時才意識到是IDT表項全空引起的兜底異常。8.2 8259A的坑中斷全被屏蔽了另一個特別容易忽略的問題init_8259A之后OCW1發(fā)0xFF把所有中斷屏蔽了外部硬件中斷根本到不了CPU。這時候你需要打開對應位。我當時測試鍵盤中斷發(fā)現(xiàn)怎么敲都沒反應查了很久才發(fā)現(xiàn)IRQ1一直是masked狀態(tài)。所以“要不要開CPU中斷”和“PIC里要不要開某個IRQ”是兩件事前者是CPU級IF標志后者是PIC級屏蔽寄存器少哪一個都不行。8.3 中斷打開后系統(tǒng)正常啟動的順序我們經常說要“先注冊后開放”其實開CPU級中斷的時間點是最后一個階段。head.s剛進保護模式時清IF是必須的因為此時IDT還沒建好。trap_init、init_IRQ都完成之后才在main里用sti打開IF。你如果一開始就讓IF1系統(tǒng)在IDT半成品狀態(tài)下一有風吹草動就崩。還有一個小細節(jié)Linux 0.11里的sti不是放在init_IRQ之后馬上做的它是在調度器第一次schedule之前才做。也就是說內核把“能響應中斷的所有條件”準備好之后才把門打開。這個思想特別值得學習不要在任何前置條件未滿足時打開中斷寧可晚一點開不要冒一點險。9. 寫在最后中斷讓內核活了起來這一章寫到這里我對中斷機制的看法已經變了不少。以前看操作系統(tǒng)教材總覺得中斷是一堆規(guī)范和術語的堆砌真正自己從零寫完一個能響應中斷的內核之后才明白“中斷”就是操作系統(tǒng)活起來的“呼吸”。沒有中斷內核只是一個執(zhí)行完就停的批處理程序有了中斷它才能感知外部世界、管理進程、調度任務。我個人的建議是如果你也在手寫操作系統(tǒng)不要只滿足于“能把Linux 0.11跑起來”。試著拆掉IDT、拆掉PIC一點一點重新加回來觀察每種現(xiàn)象的根源。這個過程比跟著別人的代碼讀十遍都有用。中斷這一章是最容易讓人崩潰的但也是最能讓人建立起“CPU硬件與軟件協(xié)作”直覺的地方。接下來寫內存分頁和進程調度時你會發(fā)現(xiàn)到處都是中斷和異常在背后撐著——到時候再回頭看這一章很多當時覺得晦澀的細節(jié)都會變得理所當然。