第4章：WSL2开发环境：安装、配置与内核开发实战

说实话，我刚开始接触WSL2时，心里是有点抵触的。毕竟搞了十几年Linux内核，总觉得Windows上跑Linux有点「不正经」。但后来项目需要，我不得不在一台Windows笔记本上搭建开发环境。试了一圈方案——虚拟机太笨重，双系统切换太麻烦，纯Cygwin又不够原生态。最后发现，WSL2还真就是那个「甜点」。

这一章，我就把WSL2从安装到内核开发实战的完整流程，掰开揉碎了讲给你听。

4.1 WSL2的安装与基础配置

先说说前提条件。你需要Windows 10版本2004以上，或者Windows 11。我建议直接用Windows 11，因为WSL2的集成度更好。嗯，这里有个坑——如果你的Windows是家庭版，可能需要手动开启一些功能。

我个人习惯用Ubuntu 22.04 LTS作为开发发行版。为什么？因为它的内核版本比较新，而且社区支持最好。安装命令很简单：

wsl --install -d Ubuntu-22.04

安装完成后，第一次启动会让你创建Linux用户名和密码。这里要注意——用户名不要用中文，否则后面编译内核时会遇到编码问题。我曾经因为这个折腾了一下午，最后发现是用户名里的中文字符搞的鬼。

4.2 Windows Terminal集成

Windows Terminal这东西，说实话比Linux自带的终端好看多了。我现在的开发机上，Windows Terminal是唯一常驻的任务栏应用。

集成WSL2很简单。安装Windows Terminal后，它会自动检测到已安装的WSL发行版。你可以在设置里调整字体、配色、背景透明度。我个人喜欢用「One Half Dark」配色方案，配上Cascadia Code字体，写代码时眼睛舒服很多。

还有一个实用配置——右键菜单集成。在Windows Terminal的设置里开启「在文件资源管理器中打开终端」选项。这样你在Windows的文件夹里右键，就能直接打开WSL2终端并定位到当前目录。这个功能我每天都在用，非常顺手。

4.3 WSL2与Windows文件互访

文件互访是WSL2的一大亮点，也是一个大坑。先说说原理：WSL2把Windows的驱动器挂载到了/mnt/目录下。比如你的C盘，在WSL2里就是/mnt/c/。

反过来，Windows也能访问WSL2的文件系统。在文件资源管理器的地址栏输入\\wsl$\Ubuntu-22.04，就能看到WSL2的完整文件系统。

正确的做法是：把代码放在WSL2的原生文件系统中，通过\\wsl$路径从Windows访问。这样两边都能操作，而且编译性能不受影响。

4.4 WSL2内核开发限制与对策

说到内核开发，WSL2有几个硬伤。我列个表格，你看完就明白了：

限制	原因	对策
无法加载自定义内核模块	WSL2内核由微软签名管理	使用insmod替代modprobe，或编译静态内核
缺少部分硬件驱动支持	WSL2是虚拟化环境	使用QEMU模拟硬件，或部署到真实硬件测试
系统调用拦截	WSL2为兼容性做了特殊处理	避免测试与Windows子系统交互的系统调用
性能瓶颈	跨文件系统IO慢	所有代码放在WSL2原生文件系统

说白了，WSL2适合做内核代码的编辑、编译和初步调试。但如果你要测试真正的内核模块加载、硬件驱动交互，还是得用虚拟机或者真机。

我个人的工作流是这样的：在WSL2里写代码、编译、做静态分析。然后通过scp把编译好的内核镜像传到一台树莓派或者服务器上，在那边做实际测试。这样既享受了Windows的桌面环境，又保证了测试的真实性。

4.5 本章知识体系

下面这张图，是我根据多年经验总结的WSL2内核开发环境全景图。你看完应该能对整个体系有个清晰的认识：

这张图把WSL2开发环境的四个核心模块串在了一起。你看，安装配置是基础，Terminal集成提升体验，文件互访是日常操作，而限制与对策则是内核开发的关键。这四个模块缺一不可。

好了，WSL2的环境就讲到这里。记住我说的——代码放原生文件系统，测试用QEMU或真机。这两个原则能帮你避开90%的坑。

---

公众号:蓝海资料掘金营，微信deep3321