TL;DR

1
2
3
4
5

sudo apt install build-essential git gdb gcc qemu-system-x86_64
git clone --depth=1 https://github.com/yuan-xy/Linux-0.11.git
cd Linux-0.11
make
make start

前言

Linux 0.11结构比较简单，主干很清晰，而且很多很好的学习资料。考虑在自己的电脑上把系统跑起来，需要解决编译和运行两个问题：

1. 如何让Linux 0.11源码兼容高版本的编译器？
2. 如何运行Linux 0.11？

在开始之前，我们假设读者已经安装了WSL（Ubuntu），以下命令如未特殊声明均在WSL中执行。此外，需要确保WSLg能正常工作，即可以在WSL下启动图形应用。

编译

在kernel.org能找到原版代码，但是这份代码只能用上古编译器（如gcc-1.4进行编译）。但是有许多项目对源代码进行了修改，使得它可以兼容现代编译器（如gcc-13.2），例如：

1. oldlinux：这是赵炯老师A Heavily Commented Linux kernel Source Code这本书对应的网站资源。今年将所有代码整理到了Github仓库oldlinux-files上，里面包含Bochs、QEMU、VMWare Workstation三种运行方式的启动镜像。
2. HIT-OSLab：这是hoverwinter同学整理的哈工大操作系统实验手册，能在Bochs上运行，但是因为年代久远不确定能否在现在的发行版环境下直接编译。
3. Linux-0.11：这是yuan-xy提供的修改过的源码和开箱即用的QEMU镜像。这份代码通过Makefile使编译和调试都可以在一条命令下完成。现在在Ubuntu 24.04的默认编译环境下通过了编译，兼容性良好。

采用第三种编译方法使用的命令如下：

1
2
3
4
5

# 假设build-essential, git, gcc和gdb包已经被安装
git clone --depth=1 https://github.com/yuan-xy/Linux-0.11.git
cd Linux-0.11
make
# 如果遇到依赖缺失，可以参考错误信息或Makefile文件补全

如果在编译的时候遇到缺失包的问题，可以使用

以上编译均要求Linux下进行，理论上Windows下的Cygwin/Msys/Msys2/MinGW也能完成，但是操作比较复杂，不如直接使用WSL或虚拟机来得方便。而由于调试需要能加载符号文件，因而编译这个过程很难绕开。因而，尽管确实可以不借助Linux发行版运行Linux 0.11，但这个过程反而更为繁琐。

运行

可用的虚拟机有三种，Bochs、QEMU和VMWare Workstation。这三种其实都能直接运行在Windows上（QEMU需要MSYS2），笔者也对编译方案一的VMWare镜像进行了测试。不过考虑到编译在Linux上比较方便，而QEMU可以启用kvm支持，我们选择QEMU作为运行环境。

以下步骤均假设你已经完成了上面方案三的编译。

运行前准备

使用发行版的包管理器安装qemu-system-x86_64：

1
2

# Ubuntu
sudo apt install qemu-system-x86_64

运行

直接使用仓库提供的Makefile中的命令即可：

1

make start

此时会弹出一个QEMU的窗口，很快就能进入到命令提示符。

调试

启动调试服务器

这一步让QEMU启动一个调试服务器，以便GDB连接。调试服务器在我们的断点位置会触发INT 3中断：

1

make debug

如果这一步提示端口占用，可以在Makefile内把debug行下的-s改成-gdb tcp::PORT，其中PORT可以选一个高位端口。 启动之后，QEMU不会立即启动BIOS，而是等待调试器连接。

GDB命令行调试

1

gdb tools/system

随后在gdb内执行target remote localhost:1234，之后就和正常流程一样完成调试即可。

VSCode集成调试

参考CSDN的方案，可以用VSCode集成的调试功能进行调试，这样方便阅读代码、打断点以及查看寄存器。

首先在打开的文件夹下创建.vscode/launch.json文件，内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/tools/system",
            "miDebuggerServerAddress": "127.0.0.1:1234",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [ 
                { 
                    "text": "set arch i386:x86-64", 
                    "description": "run target", 
                    "ignoreFailures": false 
                }
            ]
        }
    ]
}

随后在Run and Debug面板中开始调试即可，如下图所示。

DLC

Windows下用VMWare Workstation进行调试

编译方案一中的VMWare镜像，打开之后双击vmx文件即可在VMWare中打开这个虚拟机。先运行看看能不能进入系统。如果一切正常，关闭虚拟机，然后用文本编辑器修改vmx文件，添加下面几行：

1
2
3
4
5

debugStub.listen.guest32 = "TRUE"
debugStub.hideBreakpoints = "TRUE"
debugStub.listen.guest32.remote = "TRUE"
monitor.debugOnStartGuest32 = "TRUE"
bios.bootDelay = "3000" 

再启动虚拟机，发现其黑屏，此时为等待调试器连接后启动BIOS。笔者使用了方案三的tools/system进行简单测试，发现仍然可以使用命令行进行调试（连接虚拟机的8832端口，推荐先把WSL的networkingMode改成mirrored方便连接），但是VSCode集成调试会报错，如下图所示。不过由于源码不同，可能调试过程中查看代码会不匹配。

KVM加速

早期的VMWare Workstation是软件虚拟化，后续使用了Intel VT-x或AMD-V技术实现了硬件辅助虚拟化，但由于Hyper-V和各家虚拟机软件的相爱相杀（会占用Hypervisor的根分区从而排斥其它虚拟机管理器，如下图所示），实际上在启用了WSL2的机器上还是用的软件虚拟化。关于主流虚拟机架构可以参考FreeBuf的文章。

QEMU在没有KVM的情况下依靠二进制翻译，在KVM的加持下能使用硬件辅助虚拟化。而恰好WSL2基于Hyper-V，那有一个考虑是，KVM能不能也使用主机的Hypervisor虚拟化能力呢？答案是可以的，这玩意叫Nested Virtualisation。通过执行ls -al /dev/kvm，可以检查是否已经启用kvm。在本文撰写之时，这个过程已经不需要其他操作，即默认WSL2是启用虚拟化支持的。

通过配置.wslconfig文件，可以启用IO虚拟化等增强功能。我的配置文件如下。

1
2
3
4

[wsl2]
networkingMode = mirrored
memory = 20GB
kernelCommandLine=amd_iommu=on iommu=pt kvm.ignore_msrs=1 kvm-intel.enable_apicv=1

随后只要在Makefile里在start行下增加--enable-kvm参数，并且通过sudo运行make start，就能启用KVM加速。

本节参考此文章。

P.S. 通过这种方式运行的QEMU虚拟机，配合quickemu，性能和易用性或超过VMWare Workstation。