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