先把結(jié)論放在前面真正從零開(kāi)始寫(xiě)一個(gè)可用于生產(chǎn)環(huán)境的操作系統(tǒng)是國(guó)家級(jí)工程。但把“自研內(nèi)核、自研引擎、自研架構(gòu)”拆開(kāi)看每一條都有可以落地的學(xué)習(xí)路徑和實(shí)驗(yàn)空間。最近經(jīng)常刷到“自研操作系統(tǒng)”相關(guān)的討論有人曬內(nèi)核代碼量有人做渲染引擎 Demo還有人把軟件架構(gòu)圖畫(huà)得密不透風(fēng)。這類(lèi)標(biāo)題很容易讓人疑惑到底什么算“自研”內(nèi)核、引擎、架構(gòu)這三部分是什么關(guān)系如果我也想做一個(gè)小型操作系統(tǒng)應(yīng)該從哪里入手本文不吹概念不搞標(biāo)題黨直接從內(nèi)核、引擎、架構(gòu)三個(gè)維度拆解再給出一套適合個(gè)人開(kāi)發(fā)者實(shí)操的學(xué)習(xí)路線(xiàn)和實(shí)戰(zhàn)示例。1. 先拆概念內(nèi)核、引擎、架構(gòu)到底指什么“自研操作系統(tǒng)”聽(tīng)起來(lái)像是一個(gè)整體實(shí)際上它至少包含三條完全不同的技術(shù)線(xiàn)內(nèi)核、引擎和架構(gòu)。很多時(shí)候熱搜詞把三者混在一起導(dǎo)致很多人以為“沒(méi)有自己做一整套就算不上自研”這個(gè)認(rèn)知偏差需要先糾正。1.1 內(nèi)核操作系統(tǒng)的“權(quán)力中心”內(nèi)核是操作系統(tǒng)中最核心、權(quán)限最高、與硬件直接交互的部分。它負(fù)責(zé) CPU 調(diào)度、內(nèi)存管理、中斷處理、文件系統(tǒng)、設(shè)備驅(qū)動(dòng)、進(jìn)程通信等基礎(chǔ)能力。操作系統(tǒng)內(nèi)核按設(shè)計(jì)思路可以分為幾類(lèi)類(lèi)型特點(diǎn)典型代表宏內(nèi)核所有核心功能都在內(nèi)核態(tài)性能高但模塊間隔離弱Linux、FreeBSD微內(nèi)核只保留最基礎(chǔ)能力其他服務(wù)放到用戶(hù)態(tài)seL4、QNX、Minix混合內(nèi)核兼顧宏內(nèi)核性能和微內(nèi)核擴(kuò)展性Windows NT、macOS“自研內(nèi)核”在不同語(yǔ)境下含義完全不同。比如寫(xiě)一個(gè)能輸出“Hello World”的引導(dǎo)程序不算內(nèi)核寫(xiě)一個(gè)能管理內(nèi)存、調(diào)度任務(wù)、處理中斷的小型內(nèi)核就已經(jīng)是很硬核的操作系統(tǒng)實(shí)驗(yàn)項(xiàng)目了而像 Linux 那樣支撐服務(wù)器、嵌入式設(shè)備、云基礎(chǔ)設(shè)施的內(nèi)核則是數(shù)十年全球開(kāi)發(fā)者持續(xù)貢獻(xiàn)的結(jié)果。所以學(xué)習(xí)內(nèi)核目標(biāo)定位要清晰個(gè)人項(xiàng)目追求的是“理解原理、跑通實(shí)驗(yàn)”而不是“重新發(fā)明 Linux”。1.2 引擎系統(tǒng)能力的“加速層”“引擎”這個(gè)詞在不同領(lǐng)域指代不同物件但在操作系統(tǒng)語(yǔ)境下它通常指承擔(dān)某類(lèi)計(jì)算密集型任務(wù)的中間層組件。熱搜詞中出現(xiàn)了大量“渲染引擎”“物理引擎”“繪圖引擎”這些其實(shí)都屬于系統(tǒng)能力層。舉個(gè)例子渲染引擎負(fù)責(zé)把 UI 描述轉(zhuǎn)換為屏幕像素比如 Flutter 的 Impeller 渲染引擎。物理引擎負(fù)責(zé)模擬剛體碰撞、重力、約束等物理規(guī)律比如 MuJoCo、Box2D。繪圖引擎提供 2D/3D 圖形繪制能力比如瀏覽器里的 Canvas 繪圖引擎。操作系統(tǒng)層面的“自研引擎”常見(jiàn)于兩個(gè)方向自研 GUI 渲染引擎不依賴(lài)現(xiàn)成 UI 框架自定義窗口合成與繪制流程。自研瀏覽器渲染引擎將 HTML/CSS/JS 轉(zhuǎn)換成頁(yè)面像素工程量極大個(gè)人很難完整實(shí)現(xiàn)但可以做簡(jiǎn)化版。我們需要把“引擎”當(dāng)作系統(tǒng)中的可替換組件來(lái)理解。它運(yùn)行在內(nèi)核之上向下調(diào)用內(nèi)核提供的顯示、輸入、內(nèi)存能力向上為應(yīng)用層提供統(tǒng)一接口。1.3 架構(gòu)系統(tǒng)結(jié)構(gòu)的“全局藍(lán)圖”架構(gòu)不是某一塊代碼而是整個(gè)系統(tǒng)如何分層、模塊之間如何通信、數(shù)據(jù)如何流動(dòng)。常見(jiàn)的架構(gòu)模式在熱搜詞中出現(xiàn)頻率很高例如分層式架構(gòu)、微服務(wù)架構(gòu)、事件驅(qū)動(dòng)架構(gòu)、黑板模型、反應(yīng)式架構(gòu)。對(duì)于操作系統(tǒng)類(lèi)項(xiàng)目架構(gòu)設(shè)計(jì)直接決定了后續(xù)所有功能模塊能否穩(wěn)定擴(kuò)展。這里要區(qū)分兩個(gè)層面系統(tǒng)架構(gòu)CPU 指令集、內(nèi)存布局、中斷控制、特權(quán)級(jí)劃分等硬件相關(guān)設(shè)計(jì)。應(yīng)用架構(gòu)操作系統(tǒng)上運(yùn)行的軟件體系結(jié)構(gòu)比如服務(wù)端微服務(wù)、客戶(hù)端分層等。真正“自研架構(gòu)”的項(xiàng)目意味著不能直接套用現(xiàn)成的模板需要根據(jù)需求權(quán)衡模塊劃分與協(xié)作方式。新手更容易犯的錯(cuò)誤是上來(lái)就追求“通用架構(gòu)”先搭了一個(gè)過(guò)度設(shè)計(jì)的框架結(jié)果核心內(nèi)核代碼一行沒(méi)寫(xiě)。2. 內(nèi)核自研從引導(dǎo)到任務(wù)調(diào)度的最小閉環(huán)第一步是把電腦按你的想法“帶起來(lái)”。這個(gè)過(guò)程中你只會(huì)接觸到非常少的代碼但會(huì)建立對(duì)計(jì)算機(jī)啟動(dòng)流程的直觀(guān)認(rèn)識(shí)。2.1 最小引導(dǎo)程序示例以 x86 平臺(tái)為例開(kāi)機(jī)后 CPU 進(jìn)入實(shí)模式BIOS/UEFI 會(huì)把引導(dǎo)扇區(qū)加載到內(nèi)存 0x7C00 處。如果這段代碼的最后兩個(gè)字節(jié)是 0x55 0xAABIOS 就會(huì)認(rèn)為它是合法引導(dǎo)程序。; 文件路徑boot.asm BITS 16 ; 指定 16 位實(shí)模式 ORG 0x7C00 ; 指定加載地址 start: mov si, msg print: lodsb ; 讀取 SI 指向的字符到 AL同時(shí) SI 自增 or al, al jz hang ; 若字符為 0則停止 mov ah, 0x0E ; BIOS 0x10 中斷TTY 輸出模式 int 0x10 jmp print hang: hlt jmp hang msg db Hello Tiny OS, 0 times 510-($-$$) db 0 dw 0xAA55 ; 引導(dǎo)扇區(qū)結(jié)束標(biāo)志編譯命令如下nasm -f bin boot.asm -o boot.bin然后用 QEMU 模擬器運(yùn)行qemu-system-i386 -drive formatraw,fileboot.bin如果看到虛擬機(jī)屏幕上輸出Hello Tiny OS說(shuō)明你已經(jīng)完成了一個(gè)最小的“自研操作系統(tǒng)”啟動(dòng)閉環(huán)。這個(gè)實(shí)驗(yàn)雖然簡(jiǎn)單但它驗(yàn)證了整條工具鏈匯編編譯、二進(jìn)制生成、引導(dǎo)扇區(qū)格式、虛擬機(jī)加載。2.2 引入 C 語(yǔ)言與內(nèi)核入口匯編適合編寫(xiě)底層匯編代碼但寫(xiě)出復(fù)雜內(nèi)核還是要切換到 C。關(guān)鍵在于如何讓 C 語(yǔ)言編譯結(jié)果被引導(dǎo)程序加載。一種常見(jiàn)做法是將內(nèi)核鏈接到 1MB 內(nèi)存地址以上然后通過(guò)引導(dǎo)程序進(jìn)入保護(hù)模式再跳轉(zhuǎn)到 C 內(nèi)核入口。下面是極簡(jiǎn)的內(nèi)核 C 代碼// 文件路徑kernel.c void kernel_main(void) { const char *msg Kernel is running...; char *video (char *)0xB8000; // VGA 文本模式顯存地址 while (*msg) { *video *msg; // 字符 *video 0x07; // 白字黑底屬性 } while (1) { // 空循環(huán)保持系統(tǒng)運(yùn)行 } }這段代碼不依賴(lài)任何標(biāo)準(zhǔn)庫(kù)直接把字符串寫(xiě)入 VGA 顯存。運(yùn)行它的前提是你已經(jīng)配置好 GDT、進(jìn)入 32 位保護(hù)模式、并且能通過(guò)鏈接腳本把kernel_main放到正確的內(nèi)存地址。這里不展開(kāi)全部代碼只說(shuō)明步驟編寫(xiě)鏈接腳本指定內(nèi)核入口地址為 0x100000。使用gcc -m32 -ffreestanding -c kernel.c編譯為 32 位無(wú)宿主環(huán)境的二進(jìn)制。使用ld -m elf_i386 -T linker.ld鏈接。將 boot.bin 與 kernel.bin 拼接成磁盤(pán)鏡像。使用 QEMU 或真實(shí)硬件啟動(dòng)驗(yàn)證。2.3 任務(wù)調(diào)度與中斷一個(gè)內(nèi)核如果只能開(kāi)機(jī)輸出文字還遠(yuǎn)遠(yuǎn)談不上“系統(tǒng)”。常用的第二步迭代是加入時(shí)間中斷和簡(jiǎn)單的任務(wù)切換。觸發(fā)定時(shí)器中斷后內(nèi)核保存當(dāng)前任務(wù)上下文切換到下一個(gè)任務(wù)執(zhí)行。// 文件路徑sched.c核心片段 typedef struct task { uint32_t esp; // 任務(wù)棧指針 uint32_t eip; // 指令指針 int pid; struct task *next; } task_t; void schedule(void) { task_t *prev current_task; current_task current_task-next; // 切換棧與指令流 switch_to(prev-esp, current_task-esp); }任務(wù)切換的細(xì)節(jié)會(huì)涉及匯編代碼保存寄存器上下文這里不逐一展開(kāi)。但可以看出自研內(nèi)核的核心挑戰(zhàn)在于對(duì)硬件的理解、對(duì)中斷流程的編排、對(duì)內(nèi)存布局的把控。這一階段也是最能區(qū)分“調(diào)包俠”和“內(nèi)核學(xué)習(xí)者”的分水嶺。3. 引擎自研渲染、物理與計(jì)算組件內(nèi)核解決了“系統(tǒng)如何運(yùn)行”的問(wèn)題引擎解決的是“系統(tǒng)如何呈現(xiàn)復(fù)雜能力”的問(wèn)題。對(duì)于桌面級(jí)操作系統(tǒng)來(lái)說(shuō)渲染引擎是繞不開(kāi)的話(huà)題。3.1 渲染引擎的核心流程一套最簡(jiǎn)單的軟件渲染引擎可以拆為三層場(chǎng)景層維護(hù)需要繪制的圖元列表。光柵化層將幾何圖形轉(zhuǎn)換為像素?cái)?shù)據(jù)。幀緩沖層把像素?cái)?shù)據(jù)寫(xiě)入內(nèi)存幀緩沖最終由顯示驅(qū)動(dòng)輸出。這里用一個(gè)極其簡(jiǎn)化的軟件渲染示例來(lái)演示思路// 文件路徑renderer.c核心片段 #include stdint.h #define SCREEN_W 800 #define SCREEN_H 600 uint32_t framebuffer[SCREEN_W * SCREEN_H]; void clear_screen(uint32_t color) { for (int i 0; i SCREEN_W * SCREEN_H; i) { framebuffer[i] color; } } void draw_rect(int x, int y, int w, int h, uint32_t color) { for (int dy 0; dy h; dy) { for (int dx 0; dx w; dx) { int px x dx; int py y dy; if (px 0 px SCREEN_W py 0 py SCREEN_H) { framebuffer[py * SCREEN_W px] color; } } } }這個(gè)示例沒(méi)有調(diào)用任何系統(tǒng)現(xiàn)成繪圖庫(kù)完全通過(guò)像素緩沖操作實(shí)現(xiàn)畫(huà)矩形。真正的 GUI 引擎會(huì)在其上加很多層控件樹(shù)、布局計(jì)算、事件處理、離屏渲染、紋理合成等。但底層原理是一致的引擎把抽象描述變成像素。3.2 渲染引擎自研可行嗎可行但是要區(qū)分范圍。做一個(gè) 2D 軟件渲染器可以做到幾百行代碼就能實(shí)現(xiàn)基本的畫(huà)線(xiàn)、畫(huà)圓、填充、裁剪。做一個(gè) 3D 實(shí)時(shí)渲染引擎需要 GPU 驅(qū)動(dòng)、深度測(cè)試、著色器編譯、網(wǎng)格加載等大量子模塊個(gè)人項(xiàng)目通常做簡(jiǎn)化實(shí)現(xiàn)。做一個(gè)完整瀏覽器引擎工程量巨大但可以研究開(kāi)源項(xiàng)目比如 WebKit、Chromium 的架構(gòu)再實(shí)現(xiàn)一個(gè)極簡(jiǎn) HTML 布局器。工程建議是引擎自研應(yīng)當(dāng)“按需設(shè)計(jì)”先明確自己需要什么類(lèi)型引擎再規(guī)劃模塊邊界。不要一上來(lái)就做一個(gè)“萬(wàn)能引擎”否則大概率會(huì)爛尾。3.3 物理引擎與仿真組件熱搜詞里的物理引擎引起了不少人興趣。物理引擎在游戲、機(jī)器人仿真、控制算法驗(yàn)證領(lǐng)域非常常見(jiàn)。MuJoCo 就是學(xué)術(shù)界比較常用的物理引擎之一。對(duì)于自研系統(tǒng)物理引擎可以作為用戶(hù)態(tài)庫(kù)運(yùn)行不需要集成到內(nèi)核。自研一個(gè)最小物理引擎可以從以下模塊開(kāi)始碰撞檢測(cè)判斷兩個(gè)剛體是否相交。碰撞響應(yīng)根據(jù)碰撞點(diǎn)和沖量更新剛體速度。積分器使用歐拉法或龍格-庫(kù)塔法更新位置和速度。// 文件路徑physics.c核心片段 typedef struct { float x, y, vx, vy; } rigid_body; void update(rigid_body *body, float dt) { float gravity -9.8f; body-vy gravity * dt; // 速度更新 body-x body-vx * dt; // 位置更新 body-y body-vy * dt; }這個(gè)例子使用了最樸素的半隱式歐拉法。實(shí)際物理引擎需要處理約束求解、碰撞流形、矩陣運(yùn)算等復(fù)雜問(wèn)題。4. 架構(gòu)自研模塊邊界與協(xié)作機(jī)制擁有了內(nèi)核和引擎還需要一套架構(gòu)把它們組織起來(lái)。對(duì)于一個(gè)新的操作系統(tǒng)項(xiàng)目架構(gòu)設(shè)計(jì)的核心問(wèn)題包括系統(tǒng)是宏內(nèi)核還是微內(nèi)核。驅(qū)動(dòng)是內(nèi)核態(tài)加載還是用戶(hù)態(tài)服務(wù)。應(yīng)用層如何與內(nèi)核層通信。GUI 子系統(tǒng)是獨(dú)立進(jìn)程還是內(nèi)核線(xiàn)程。4.1 分層架構(gòu)最常見(jiàn)的操作系統(tǒng)項(xiàng)目架構(gòu)是分層模型。以一個(gè)小型系統(tǒng)為例大致可以分為應(yīng)用層 ─────────────── 系統(tǒng)庫(kù)層C 庫(kù)、GUI 工具庫(kù) ─────────────── 內(nèi)核服務(wù)層文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧、進(jìn)程管理 ─────────────── 硬件抽象層驅(qū)動(dòng)接口、中斷控制 ─────────────── 硬件層CPU、內(nèi)存、外設(shè)采用分層架構(gòu)的好處是每個(gè)模塊職責(zé)清晰依賴(lài)方向單向向下。缺點(diǎn)是嚴(yán)格分層可能帶來(lái)性能損耗如果層與層之間過(guò)度抽象代碼會(huì)變得繁瑣。4.2 事件驅(qū)動(dòng)架構(gòu)熱搜詞中出現(xiàn)了“從超級(jí)大循環(huán)到事件驅(qū)動(dòng)嵌入式架構(gòu)升級(jí)的分水嶺”這句話(huà)很有代表性。很多嵌入式系統(tǒng)和操作系統(tǒng)內(nèi)核都經(jīng)歷從超級(jí)循環(huán)到事件驅(qū)動(dòng)的演進(jìn)。超級(jí)循環(huán)模式while (1) { handle_keyboard(); handle_mouse(); handle_network(); update_gui(); }事件驅(qū)動(dòng)模式// 事件隊(duì)列 struct event { int type; int data; }; struct event queue[64]; int head 0; int tail 0; void post_event(int type, int data) { queue[tail] (struct event){type, data}; tail (tail 1) % 64; } struct event poll_event(void) { struct event ev queue[head]; head (head 1) % 64; return ev; }事件驅(qū)動(dòng)的核心是“何時(shí)有事何時(shí)處理”而不是“不斷輪詢(xún)所有設(shè)備”。這種架構(gòu)在 GUI 系統(tǒng)、網(wǎng)絡(luò)服務(wù)、游戲引擎中都是主流。理解了事件驅(qū)動(dòng)再去讀內(nèi)核的中斷處理、消息機(jī)制會(huì)順暢很多。4.3 微服務(wù)與反應(yīng)式架構(gòu)一部分熱搜詞指向微服務(wù)架構(gòu)和反應(yīng)式架構(gòu)這些更多屬于上層軟件設(shè)計(jì)。如果你做的是面向服務(wù)器場(chǎng)景的操作系統(tǒng)周邊軟件才會(huì)涉及這些概念。微服務(wù)架構(gòu)把大單體拆成獨(dú)立部署的小服務(wù)通過(guò)消息通信協(xié)作。反應(yīng)式架構(gòu)圍繞數(shù)據(jù)流和變化傳播強(qiáng)調(diào)響應(yīng)性、彈性、伸縮性。黑板模型多個(gè)獨(dú)立模塊共享一個(gè)“黑板”數(shù)據(jù)區(qū)各自讀寫(xiě)并協(xié)作完成任務(wù)適合 AI 和復(fù)雜問(wèn)題求解場(chǎng)景。“自研架構(gòu)”的重點(diǎn)并不是發(fā)明一種全新架構(gòu)而是能夠結(jié)合應(yīng)用場(chǎng)景選擇、組合、裁剪已有架構(gòu)模式。很多號(hào)稱(chēng)“自研架構(gòu)”的項(xiàng)目實(shí)際是把已有的模式重新組合了一遍這并不丟人關(guān)鍵在于是否理解每種模式的適用邊界和代價(jià)。5. 自研操作系統(tǒng)技術(shù)棧全景與學(xué)習(xí)路線(xiàn)如果你真的想動(dòng)手做一個(gè)偏完整的個(gè)人操作系統(tǒng)需要考慮的知識(shí)面非常廣。下面是一個(gè)不依賴(lài)商業(yè)項(xiàng)目的技術(shù)棧清單。5.1 底層基礎(chǔ)匯編語(yǔ)言x86 匯編或 ARM 匯編。C 語(yǔ)言?xún)?nèi)存操作、指針、位運(yùn)算、函數(shù)調(diào)用約定。計(jì)算機(jī)組成原理CPU、內(nèi)存、總線(xiàn)、外設(shè)、中斷控制器。鏈接與加載ELF 格式、鏈接腳本、段布局、重定位。5.2 內(nèi)核主題引導(dǎo)流程BIOS/UEFI、MBR/GPT、引導(dǎo)加載器。內(nèi)存管理分頁(yè)、分段、頁(yè)表、物理內(nèi)存分配器、虛擬內(nèi)存區(qū)域。進(jìn)程管理進(jìn)程控制塊、上下文切換、調(diào)度算法。中斷與異常IDT、中斷描述符、中斷處理、系統(tǒng)調(diào)用。驅(qū)動(dòng)模型設(shè)備樹(shù)、PCI 枚舉、驅(qū)動(dòng)注冊(cè)與回調(diào)。文件系統(tǒng)VFS 抽象、塊設(shè)備驅(qū)動(dòng)、簡(jiǎn)單文件格式。5.3 引擎主題GUI窗口管理、控件繪制、事件分發(fā)。渲染2D 光柵化、字體渲染、幀緩沖。物理剛體動(dòng)力學(xué)、碰撞檢測(cè)、約束求解。聲音音頻緩沖區(qū)、混音、設(shè)備輸出。5.4 架構(gòu)主題分層宏內(nèi)核/微內(nèi)核。服務(wù)化內(nèi)核服務(wù) vs 用戶(hù)態(tài)服務(wù)。并發(fā)鎖、信號(hào)量、消息隊(duì)列。可靠性異常隔離、重啟策略。5.5 推薦學(xué)習(xí)路線(xiàn)階段目標(biāo)關(guān)鍵實(shí)驗(yàn)階段一理解啟動(dòng)流程寫(xiě)出可啟動(dòng)的引導(dǎo)扇區(qū)階段二掌握保護(hù)模式與分頁(yè)從實(shí)模式切換 32 位模式階段三實(shí)現(xiàn)中斷與鍵盤(pán)輸入編寫(xiě) IDT 和鍵盤(pán)驅(qū)動(dòng)階段四實(shí)現(xiàn)進(jìn)程調(diào)度兩個(gè)任務(wù)交替運(yùn)行階段五實(shí)現(xiàn)輕量 GUI窗口繪制、鼠標(biāo)事件階段六添加文件系統(tǒng)創(chuàng)建并讀取簡(jiǎn)單文件6. 常見(jiàn)問(wèn)題與排查思路自研操作系統(tǒng)是一個(gè)極致依賴(lài)細(xì)節(jié)的領(lǐng)域報(bào)錯(cuò)往往沒(méi)有框架那樣友好的堆棧提示。下面匯總幾個(gè)高頻問(wèn)題與排查方法。6.1 引導(dǎo)扇區(qū)不生效問(wèn)題現(xiàn)象常見(jiàn)原因解決思路Q(chēng)EMU 黑屏或提示 no bootable device引導(dǎo)標(biāo)志 0x55AA 位置錯(cuò)誤檢查扇區(qū)大小是否確實(shí)為 512 字節(jié)代碼執(zhí)行異常跳轉(zhuǎn)段寄存器或地址計(jì)算錯(cuò)誤檢查 ORG 指令是否與加載地址匹配屏幕輸出亂碼顯存地址或?qū)傩宰止?jié)錯(cuò)誤確認(rèn) VGA 文本模式地址 0xB80006.2 內(nèi)核編譯鏈接失敗問(wèn)題現(xiàn)象常見(jiàn)原因解決思路undefined reference to main鏈接腳本入口與源碼符號(hào)不一致檢查 ENTRY 和函數(shù)名multipart text section overflow內(nèi)核代碼超出預(yù)分配大小調(diào)整鏈接腳本段布局file not recognized編譯器與鏈接器架構(gòu)不匹配統(tǒng)一使用 -m32 和 elf_i3866.3 中斷不觸發(fā)或死循環(huán)加中斷后系統(tǒng) Hang 住常見(jiàn)原因是中斷控制器未初始化或者中斷處理函數(shù)沒(méi)有正確使用iret指令返回?？梢栽谥袛嗪瘮?shù)入口和出口分別寫(xiě)入調(diào)試字符判斷函數(shù)是否進(jìn)入。// 中斷入口寫(xiě)入顯存調(diào)試用 void keyboard_handler(void) { char *video (char *)0xB8000; video[160] K; video[161] 0x04; // 其他中斷處理邏輯 }6.4 與 Linux 內(nèi)核相關(guān)問(wèn)題的補(bǔ)充說(shuō)明熱搜詞中出現(xiàn)“l(fā)inux 內(nèi)核無(wú)法給 pcie 橋接器分配足夠的內(nèi)存映射空間”這類(lèi)報(bào)錯(cuò)這是真實(shí)場(chǎng)景中硬件資源分配問(wèn)題。出現(xiàn)類(lèi)似問(wèn)題時(shí)排查方向通常如下查看lspci -vvv打印的 BAR 信息。確認(rèn) BIOS 的Above 4G Decoding、MMIO相關(guān)設(shè)置。嘗試內(nèi)核參數(shù)pcirealloc、pciassign-buses但注意生產(chǎn)環(huán)境需在維護(hù)窗口驗(yàn)證。確認(rèn)設(shè)備需要的地址空間是否與系統(tǒng)預(yù)留區(qū)域沖突。這類(lèi)問(wèn)題屬于發(fā)行版、硬件兼容性的綜合排查不適合在開(kāi)發(fā)板上隨意測(cè)試。涉及生產(chǎn)設(shè)備操作時(shí)務(wù)必先在測(cè)試環(huán)境驗(yàn)證并做好配置備份。6.5 虛擬機(jī) CPU 相關(guān)報(bào)錯(cuò)“客戶(hù)機(jī)操作系統(tǒng)已禁用 CPU。請(qǐng)關(guān)閉或重置虛擬機(jī)”這類(lèi)提示多半與虛擬機(jī)配置有關(guān)。需要檢查BIOS 的虛擬化功能是否開(kāi)啟。虛擬機(jī) CPU 模式是否選擇正確。是否誤設(shè)了過(guò)多的 vCPU 核心數(shù)。另外“指定的可執(zhí)行文件不是此操作系統(tǒng)平臺(tái)的有效應(yīng)用程序”這類(lèi)錯(cuò)誤通常是因?yàn)榭蓤?zhí)行文件架構(gòu)與系統(tǒng)不一致。比如在 ARM Linux 上運(yùn)行 x86 編譯產(chǎn)物或者 32 位程序直接在純 64 位系統(tǒng)上運(yùn)行。排查時(shí)使用file命令查看二進(jìn)制格式即可。7. 最佳實(shí)踐與工程建議自研操作系統(tǒng)不可能一蹴而就想長(zhǎng)期迭代下去工程方法很關(guān)鍵。7.1 從最小閉環(huán)開(kāi)始迭代先把“開(kāi)機(jī) → 輸出字符 → 進(jìn)入死循環(huán)”的最小系統(tǒng)跑起來(lái)。之后每添加一個(gè)新功能都確保系統(tǒng)仍然可以啟動(dòng)和觀(guān)察輸出。不要一次性寫(xiě)大量代碼再調(diào)試否則定位問(wèn)題會(huì)非常困難。7.2 善用虛擬機(jī)和版本管理QEMU 是最適合內(nèi)核實(shí)驗(yàn)的模擬器可以單步調(diào)試、查看寄存器、dump 內(nèi)存。配合 Makefile 自動(dòng)化編譯和啟動(dòng)流程可以大幅減少手工操作。# 文件路徑Makefile CC gcc LD ld NASM nasm CFLAGS -m32 -ffreestanding -fno-stack-protector -O2 LDFLAGS -m elf_i386 -T linker.ld all: os.img boot.bin: boot.asm $(NASM) -f bin boot.asm -o boot.bin kernel.bin: kernel.o $(LD) $(LDFLAGS) -o kernel.bin kernel.o kernel.o: kernel.c $(CC) $(CFLAGS) -c kernel.c -o kernel.o os.img: boot.bin kernel.bin cat boot.bin kernel.bin os.img run: os.img qemu-system-i386 -drive formatraw,fileos.img .PHONY: clean clean: rm -f *.o *.bin os.img7.3 日志比調(diào)試器更重要內(nèi)核沒(méi)有成熟的日志框架時(shí)直接寫(xiě) VGA 內(nèi)存即可。但更需要維護(hù)一套分級(jí)日志機(jī)制普通信息、警告、錯(cuò)誤分別輸出到不同位置。這樣在系統(tǒng)崩潰時(shí)可以快速定位是哪個(gè)模塊出錯(cuò)。7.4 分離硬件依賴(lài)與純邏輯在編寫(xiě)驅(qū)動(dòng)時(shí)將“讀取寄存器”和“業(yè)務(wù)邏輯”分離。比如鍵盤(pán)驅(qū)動(dòng)負(fù)責(zé)讀取掃描碼然后把掃描碼交給上層解析層上層不應(yīng)該知道底層端口地址。這樣做的好處是后期換成 USB 鍵盤(pán)時(shí)上層代碼不需要改動(dòng)。7.5 安全邊界意識(shí)自研操作系統(tǒng)實(shí)驗(yàn)必須在虛擬機(jī)、開(kāi)發(fā)板等隔離環(huán)境進(jìn)行。不要輕易在主力機(jī)上測(cè)試引導(dǎo)程序避免破壞現(xiàn)有系統(tǒng)引導(dǎo)。所有涉及磁盤(pán)、分區(qū)、引導(dǎo)扇區(qū)的操作都要確認(rèn)目標(biāo)設(shè)備。如果要在真實(shí)硬件上測(cè)試建議使用專(zhuān)門(mén)準(zhǔn)備的測(cè)試機(jī)并提前備份所有重要數(shù)據(jù)。8. 總結(jié)與下一步學(xué)習(xí)建議回到標(biāo)題的問(wèn)題自研內(nèi)核、自研引擎、自研架構(gòu)的操作系統(tǒng)到底能做成什么樣從技術(shù)本質(zhì)來(lái)說(shuō)這三者在真實(shí)產(chǎn)品中是分層協(xié)作的關(guān)系內(nèi)核管理硬件資源引擎提供計(jì)算與渲染能力架構(gòu)決定模塊邊界與通信機(jī)制。個(gè)人完全可以逐個(gè)擊破內(nèi)核方向從引導(dǎo)代碼、中斷控制、分頁(yè)內(nèi)存做起。引擎方向從軟件渲染器、極小 GUI、2D 物理模塊做起。架構(gòu)方向從分層模型、事件循環(huán)、內(nèi)核/用戶(hù)態(tài)消息機(jī)制做起。下一步可以根據(jù)你自己的工作方向選擇分支。如果是嵌入式方向重點(diǎn)研究嵌入式內(nèi)核、實(shí)時(shí)調(diào)度、驅(qū)動(dòng)模型如果是圖形應(yīng)用方向重點(diǎn)研究渲染引擎、GUI 事件流、圖形 API如果是后端方向可以把重點(diǎn)放在微服務(wù)架構(gòu)、反應(yīng)式架構(gòu)與系統(tǒng)調(diào)用的關(guān)系上。學(xué)習(xí)這件事最忌諱的就是只收藏不實(shí)現(xiàn)。建議你本周就搭好 QEMU 環(huán)境用 NASM 寫(xiě)一個(gè)最小引導(dǎo)扇區(qū)先聽(tīng)到終端里那聲真實(shí)的“Hello Tiny OS”。后面每一次崩潰、花屏、死循環(huán)都是理解操作系統(tǒng)的最好教材。