1. 为什么我要从 Source Insight 迁移到 VSCode Clangd搞嵌入式 Linux 内核这一行的Source Insight 几乎是绕不开的工具。我用了差不多六年从最早读 U-Boot 源码到后来啃 Linux 内核的网络子系统SI 的代码跳转和关系窗口确实帮了不少忙。但这两年情况变了尤其是手头这块韦东山 IMX6ULL 的开发板到手之后我发现 SI 越来越跟不上节奏。最直接的问题是索引速度。Linux 内核源码现在动辄六万多个文件SI 建一次全量索引我这台 i7 加 32G 内存的机器要跑将近四十分钟中途还经常卡死。更麻烦的是内核代码里大量使用宏定义、条件编译、函数指针SI 的解析器对这些现代 C 代码的语义理解能力有限经常出现跳转错误或者干脆跳不过去。比如container_of这种内核里满地都是的宏SI 有时候能识别有时候就给你跳到一堆莫名其妙的地方。另一个让我下定决心换工具的原因是工作流割裂。我平时写应用层代码用 VSCode写脚本用 VSCode连写文档都用 VSCode唯独读内核代码要切回 SI。而且 SI 在 Linux 环境下跑不了我平时主力开发环境是 Ubuntu只能开虚拟机或者远程桌面体验很差。VSCode 原生跨平台配合 Remote-SSH 可以直接连到编译服务器上读代码这个优势太明显了。那为什么是 Clangd 而不是 VSCode 自带的 C/C 插件这里有个关键区别。微软的 C/C 插件用的是 Tag Parser本质上还是基于文本的符号索引对宏展开和模板推导的支持有限。Clangd 背后是 LLVM 的 Clang 编译器前端它是真正在编译层面理解代码的。也就是说Clangd 能看到编译器看到的东西——宏展开后的真实代码、条件编译的实际分支、函数指针的具体指向。对于 Linux 内核这种宏定义满天飞、条件编译层层嵌套的代码库这个差别是决定性的。我拿 IMX6ULL 这块板子实测下来Clangd 配合compile_commands.json编译数据库跳转准确率比 SI 高出一个量级。像platform_driver_register这种通过宏层层包装的注册函数Clangd 能直接跳到最终的结构体定义SI 就只能跳到宏定义那一层。而且 Clangd 的补全是基于语义的你敲一个结构体指针它能根据类型推断出成员列表这个体验在阅读内核代码时特别有用。这套方案适合谁我觉得三类人最值得折腾一是正在学习 Linux 内核驱动开发的嵌入式工程师手头有类似 IMX6ULL、正点原子这类开发板二是需要频繁阅读和修改内核代码的系统软件工程师三是习惯 VSCode 工作流、不想在多个编辑器之间来回切换的开发者。如果你只是偶尔翻翻内核源码那 SI 或者直接上 elixir.bootlin.com 在线看可能更省事。但如果你是重度内核代码阅读者这套环境搭好之后效率提升是实打实的。2. 环境搭建的整体思路与关键选型2.1 为什么需要编译数据库这个中间层Clangd 工作的核心依赖是一个叫compile_commands.json的文件这东西是整套方案的关键。它的作用说白了就是告诉 Clangd每个源文件在编译时用了哪些参数、定义了哪些宏、包含了哪些头文件路径。没有这个文件Clangd 就退化成一个普通的文本索引器跟 SI 没什么区别。Linux 内核的编译系统是 Kbuild它不像 CMake 那样原生支持导出编译数据库。所以我们需要借助一个工具叫bear它的原理是拦截编译过程中的execve系统调用把每次调用编译器时的完整命令行参数记录下来最后汇总成 JSON 格式的编译数据库。这个思路很巧妙不需要修改内核的 Makefile对源码零侵入。这里有个坑要注意内核编译过程中会编译大量主机工具比如scripts/目录下的各种辅助程序这些也会被 bear 记录下来。如果不做过滤生成的compile_commands.json会包含很多无关条目Clangd 索引时会浪费大量时间。我后面会讲怎么处理这个问题。2.2 VSCode 插件选型Clangd 与 C/C 的取舍VSCode 里跟 C/C 相关的插件主要有三个微软官方的 C/C、Clangd、以及 C/C Extension Pack。我的建议是只装 Clangd把微软的 C/C 插件禁用掉。这两个插件同时启用会打架因为它们都想接管代码跳转和补全功能结果就是跳转行为不稳定有时候跳到 Clangd 的结果有时候跳到 C/C 插件的结果。Clangd 插件本身很轻量它只是一个前端真正的分析引擎是后台运行的clangd语言服务器。这个服务器需要单独安装Ubuntu 下直接apt install clangd就行但要注意版本。Ubuntu 20.04 自带的 clangd 是 10.0 版本对内核代码的支持不够好建议至少用 14.0 以上。我实测用的是 15.0.7配合内核 4.19 源码跳转和补全都很稳。另外还需要装一个辅助插件叫clangd-format或者直接用clang-format这个不是必须的但如果你需要按照内核代码风格格式化代码会很有用。内核有自己的.clang-format文件在源码根目录下Clangd 会自动识别。2.3 目标平台与源码版本说明我这次实测用的是韦东山 IMX6ULL 开发板配套的 Linux 4.19.71 内核源码这是 NXP 官方 BSP 里带的版本。选择这个版本有两个原因一是它足够稳定社区支持好二是它的编译系统比较标准没有太多厂商私有的构建脚本适合作为通用方案的验证。源码目录结构是标准的 Linux 内核布局顶层有arch/、drivers/、fs/、kernel/等目录。交叉编译工具链用的是arm-linux-gnueabihf-这是韦东山教程里推荐的工具链。如果你用的是正点原子的 IMX6ULL 板子工具链名字可能略有不同但整体流程完全一样。需要提前说明的是这套方案不依赖具体的开发板硬件你甚至不需要真的有一块板子。只要你能拿到内核源码并且能成功编译一次就能生成编译数据库。开发板的作用只是让你能实际验证代码修改的效果对于纯代码阅读来说不是必需的。3. 从零开始搭建环境的完整实操3.1 基础工具链安装与版本确认先确认系统环境。我用的是 Ubuntu 20.04 LTS这是目前嵌入式开发最常用的桌面发行版。如果你用其他版本或者别的发行版命令略有差异但思路一样。第一步装编译内核需要的依赖包sudo apt update sudo apt install -y build-essential libncurses-dev bison flex \ libssl-dev libelf-dev bc git bear clangd这里重点说几个包的作用。libncurses-dev是make menuconfig图形化配置界面需要的bison和flex是内核构建系统用来生成语法分析器的libssl-dev和libelf-dev是编译内核模块签名和 ELF 解析相关功能需要的bc是内核构建脚本里做数学计算用的。bear和clangd就是前面说的核心工具。装完之后确认版本clangd --version bear --version我这边 clangd 输出的是clangd version 15.0.7bear 是3.0.20。如果你的 clangd 版本低于 14建议从 LLVM 官方源装新版本否则对内核代码里的一些 GNU 扩展语法支持不好。交叉编译工具链的安装取决于你用的板子。韦东山 IMX6ULL 的教程里通常会让装gcc-arm-linux-gnueabihf直接 apt 装就行sudo apt install -y gcc-arm-linux-gnueabihf arm-linux-gnueabihf-gcc --version确认能输出版本信息就说明工具链就绪了。3.2 内核源码准备与首次编译把内核源码解压到工作目录我习惯放在~/work/kernel/下面mkdir -p ~/work/kernel cd ~/work/kernel tar -xvf linux-4.19.71-imx6ull.tar.gz cd linux-4.19.71首次编译之前需要配置内核。韦东山的教程里通常会提供一个默认配置文件在arch/arm/configs/目录下名字类似imx6ull_defconfig或者mx6ull_14x14_evk_defconfig。用哪个取决于你的板子型号我这边用的是imx6ull_defconfigmake ARCHarm CROSS_COMPILEarm-linux-gnueabihf- imx6ull_defconfig这一步会生成.config文件。如果你想调整配置可以跑make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig但为了生成编译数据库用默认配置就够了。接下来是关键的编译步骤。这里不要直接用 bear 包住 make因为内核编译会调用成千上万次编译器bear 全部记录会产生一个巨大的 JSON 文件而且包含大量无关条目。我的做法是先正常编译一次确保编译能通过然后再用 bear 重新编译一次只记录我们关心的部分。先正常编译make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j$(nproc)这一步大概需要十几分钟到半小时取决于机器性能。编译成功后清理一下构建产物但保留.configmake ARCHarm CROSS_COMPILEarm-linux-gnueabihf- clean注意是clean不是mrpropermrproper会把.config也删掉。3.3 用 Bear 生成编译数据库的正确姿势现在用 bear 重新编译生成编译数据库bear -- make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j$(nproc)bear 3.0 之后的版本用法有变化老版本是bear make ...新版本是bear -- make ...中间要加--。这个细节很多教程没更新容易踩坑。编译完成后当前目录下会生成compile_commands.json。先看看它有多大ls -lh compile_commands.json wc -l compile_commands.json我这边生成的文件大概 80MB有六万多条记录。这个体积对 Clangd 来说太大了索引一次要很久而且很多条目是编译主机工具的跟内核代码阅读无关。3.4 编译数据库的过滤与优化过滤的思路很简单只保留arch/arm/、drivers/、fs/、kernel/、mm/、net/这些我们真正关心的目录下的源文件条目把scripts/、tools/、usr/这些主机工具的条目去掉。我写了一个 Python 脚本来做这件事import json import os # 需要保留的目录前缀 KEEP_PREFIXES [ arch/arm/, drivers/, fs/, kernel/, mm/, net/, ipc/, security/, block/, crypto/, lib/, sound/, ] def should_keep(entry): directory entry.get(directory, ) filepath entry.get(file, ) # 获取相对于内核根目录的路径 if directory.endswith(linux-4.19.71): rel_path filepath else: # 处理子目录中的文件 rel_path os.path.relpath(filepath, directory) for prefix in KEEP_PREFIXES: if rel_path.startswith(prefix): return True return False with open(compile_commands.json, r) as f: data json.load(f) filtered [entry for entry in data if should_keep(entry)] with open(compile_commands_filtered.json, w) as f: json.dump(filtered, f, indent2) print(f原始条目数: {len(data)}) print(f过滤后条目数: {len(filtered)})跑一下这个脚本我这边过滤后剩下大概两万条记录文件大小降到 25MB 左右。然后把它重命名成 Clangd 认识的名字mv compile_commands_filtered.json compile_commands.json注意过滤脚本里的路径判断逻辑要根据你的实际目录结构调整。如果你的源码不在linux-4.19.71这个目录名下需要相应修改。3.5 VSCode 与 Clangd 插件的配置细节打开 VSCode在扩展市场里搜索clangd安装由 LLVM 团队发布的那个。安装完成后务必禁用微软的 C/C 插件否则两者会冲突。禁用方法是在扩展面板里找到 C/C 插件点击齿轮图标选择禁用。接下来配置 Clangd。在项目根目录下创建.vscode/settings.json{ clangd.arguments: [ --compile-commands-dir${workspaceFolder}, --background-index, --clang-tidy, --completion-styledetailed, --header-insertionnever, --query-driver/usr/bin/arm-linux-gnueabihf-*, -j8, --loginfo ], clangd.path: /usr/bin/clangd, files.associations: { *.h: c }, C_Cpp.intelliSenseEngine: disabled }逐条解释这些参数的作用。--compile-commands-dir指定编译数据库所在目录${workspaceFolder}是 VSCode 的变量指向当前打开的文件夹。--background-index让 Clangd 在后台建立索引不阻塞前台操作。--clang-tidy启用静态检查能帮你发现一些潜在的代码问题。--completion-styledetailed让补全列表显示更详细的信息比如函数签名和返回类型。--header-insertionnever禁止 Clangd 自动插入头文件这个在内核代码里很重要因为内核的头文件包含关系很讲究自动插入容易搞乱。--query-driver告诉 Clangd 去哪里找交叉编译器的系统头文件这个参数对内核代码特别关键不设置的话 Clangd 找不到stddef.h这类编译器内置头文件会报一堆错。-j8限制索引线程数避免吃满 CPU。files.associations把.h文件关联为 C 语言因为内核头文件都是 C 的不这样设置 VSCode 可能按 C 解析导致一些语法误报。配置好之后重启 VSCode打开内核源码目录。Clangd 会自动开始索引右下角会显示索引进度。第一次索引大概需要五到十分钟取决于机器性能。索引完成后代码跳转、补全、悬停提示就都能用了。4. 实测效果与常见问题排查4.1 跳转准确率与补全体验实测拿几个内核里典型的复杂场景来测试。第一个是container_of宏这个宏在内核里用来从成员指针反推结构体指针定义在include/linux/kernel.h里。在 SI 里跳转container_of只能跳到宏定义那一行看不到实际展开后的代码。Clangd 配合编译数据库能正确展开宏你悬停在container_of上会看到展开后的完整表达式跳转到成员定义也能正确解析。第二个是platform_driver_register这类通过宏包装的注册函数。在内核里很多注册函数都是宏实际调用的是带__前缀的内部函数。SI 跳转只能到宏定义Clangd 能直接跳到__platform_driver_register的实现。这个差别在阅读驱动代码时特别明显因为驱动代码里到处都是这类宏。第三个是函数指针的跳转。内核里大量使用函数指针实现回调机制比如文件操作结构体file_operations里的read、write等成员。SI 对函数指针的解析基本靠猜经常跳错。Clangd 基于类型系统能根据赋值的具体函数推断出指针指向跳转准确率高很多。补全体验方面Clangd 的语义补全比 SI 的文本补全强太多。比如你有一个struct device *dev指针敲dev-之后Clangd 会列出struct device的所有成员而且按类型分组带类型标注。SI 的补全只是基于文本匹配经常列出一堆不相关的符号。4.2 索引慢、内存占用高的调优方法Clangd 索引内核这种大项目内存占用确实不低。我实测下来索引过程中 clangd 进程大概吃 4 到 6GB 内存索引完成后稳定在 2GB 左右。如果你的机器内存小于 16GB可能会有点吃力。几个调优手段。第一是前面说的过滤编译数据库把无关条目去掉能显著减少索引量。第二是调整-j参数如果你的 CPU 核心少把并行索引线程数降下来虽然索引慢一点但不会把机器卡死。第三是关闭--clang-tidy静态检查很吃 CPU如果你不需要这个功能去掉这个参数能加快索引速度。还有一个技巧是分目录索引。如果你主要看驱动代码可以只保留drivers/目录下的条目这样索引量能再降一个数量级。方法就是修改前面过滤脚本里的KEEP_PREFIXES只留你关心的目录。4.3 常见报错与解决方案速查实际搭建过程中会遇到各种报错我整理了一个速查表报错信息原因解决方法Failed to find compile_commands.json编译数据库不在工作目录下确认compile_commands.json在 VSCode 打开的根目录或修改--compile-commands-dir参数stddef.h file not foundClangd 找不到交叉编译器的内置头文件设置--query-driver参数指向交叉编译器路径Too many errors emitted, stopping now编译数据库里的宏定义与 Clangd 默认配置冲突检查compile_commands.json里的-D参数确保与内核配置一致跳转全部失效C/C 插件与 Clangd 冲突禁用微软 C/C 插件只保留 Clangd索引卡在某个百分比不动某个源文件解析出错导致卡死查看 Clangd 日志--logverbose找到出错的源文件从编译数据库中移除补全列表为空索引未完成或编译数据库路径错误等待索引完成检查 VSCode 右下角 Clangd 状态图标clangd进程占用 CPU 100%后台索引正在进行正常现象等待索引完成或降低-j参数4.4 几个我踩过的坑和独家技巧第一个坑是编译数据库的路径问题。bear 生成的compile_commands.json里directory字段是绝对路径file字段也是绝对路径。如果你把源码目录移动了位置这些路径就全失效了。解决办法是生成编译数据库之后不要移动源码目录或者写脚本批量替换路径。第二个坑是内核配置变化后需要重新生成编译数据库。如果你改了.config比如开启了新的驱动或者关闭了某些功能编译数据库里的宏定义就过时了Clangd 的解析结果会跟实际编译结果不一致。所以每次改配置之后都要重新跑一遍 bear 编译。第三个技巧是用.clangd配置文件做项目级配置。除了 VSCode 的settings.jsonClangd 还支持在项目根目录放一个.clangd文件格式是 YAML。这个文件的好处是跟编辑器无关团队协作时可以提交到 git 仓库大家共享同一套配置。我的.clangd文件长这样CompileFlags: Add: - -Wno-everything Remove: - -mno-fp-ret-in-387 Diagnostics: Suppress: - unknown-argument - invalid-argumentAdd里的-Wno-everything是关闭所有编译警告因为内核代码里有很多 GNU 扩展语法Clangd 会报一堆警告关掉之后清爽很多。Remove里的-mno-fp-ret-in-387是内核编译时用的一个 x86 特有参数在 ARM 平台上 Clangd 不认识会报错所以移除掉。Diagnostics.Suppress是抑制一些已知的误报。第四个技巧是利用 Clangd 的--background-index-priority参数。这个参数可以设置后台索引的优先级默认是normal如果你觉得索引时机器太卡可以设成low索引会慢一点但前台操作更流畅。5. 从 SI 迁移过来的工作流适配建议5.1 快捷键与操作习惯的转换从 SI 迁移到 VSCode最大的不适应是快捷键。SI 里Ctrl左键是跳转VSCode 里默认也是Ctrl左键这个倒是一致。但 SI 的Alt,和Alt.是前进后退VSCode 里对应的是CtrlAlt-和CtrlShift-需要适应一下。我建议装一个叫AltLeft/Right的键位映射或者直接在 VSCode 的键盘快捷方式设置里把后退和前进绑定到AltLeft和AltRight这样跟浏览器和大多数 IDE 的习惯一致。SI 的关系窗口Relation Window是它的招牌功能能显示当前符号的所有引用。VSCode 里对应的是查找所有引用快捷键ShiftF12效果类似但展示方式不同。Clangd 的引用查找是基于语义的比 SI 的文本匹配准确。5.2 多文件搜索与符号导航的替代方案SI 的全局搜索Ctrl/在 VSCode 里对应的是CtrlShiftF功能更强支持正则和文件类型过滤。但要注意VSCode 的搜索默认不搜索.gitignore里的文件内核源码里有些文件可能被忽略了需要在搜索设置里调整。符号导航方面SI 的符号窗口在 VSCode 里对应的是CtrlShiftO可以按文件名或符号名快速跳转。Clangd 还提供了一个更强的功能叫工作区符号搜索快捷键CtrlT可以跨文件搜索所有符号输入函数名或结构体名就能直接跳过去。5.3 团队协作时的配置共享如果你在团队里推广这套方案建议把.vscode/settings.json和.clangd文件都提交到 git 仓库。但compile_commands.json不要提交因为它跟具体的编译环境相关每个人的工具链路径可能不同。可以在 README 里写清楚生成编译数据库的步骤让每个人自己生成。另外如果团队里有人用 Windows 有人用 Linux编译数据库的路径格式会不一样。Windows 下路径是反斜杠Linux 下是正斜杠。Clangd 在 Windows 下能处理反斜杠但为了统一建议在 Windows 下也用正斜杠或者用 WSL 环境。6. 内核代码阅读的几个实战技巧6.1 利用 Clangd 的类型推导理解复杂宏内核里有很多复杂的宏比如DEFINE_MUTEX、DECLARE_COMPLETION、module_init等等。这些宏展开后往往是一大坨代码直接看宏定义很难理解。Clangd 的悬停提示能显示宏展开后的结果这个功能在阅读这类代码时特别有用。举个例子module_init宏在include/linux/module.h里定义展开后是一个initcall_t类型的函数指针被放到特定的 section 里。你悬停在module_init上Clangd 会显示展开后的完整代码你就能看到它实际做了什么。这个比翻宏定义一层层找快多了。6.2 条件编译分支的快速定位内核代码里条件编译特别多#ifdef CONFIG_XXX满天飞。SI 对这些分支的处理很粗糙经常把所有分支都显示出来看得眼花。Clangd 根据编译数据库里的-D参数知道哪些CONFIG_XXX是开启的哪些是关闭的所以它只显示实际生效的分支。这个功能在阅读驱动代码时特别有用。比如一个驱动支持多种硬件变体代码里用#ifdef区分Clangd 会根据你的内核配置只显示当前配置对应的代码路径其他分支会灰显或者折叠。这样你看到的代码就是实际编译进内核的代码不会被无关分支干扰。6.3 跨文件调用链的追踪方法阅读内核代码经常需要追踪一个函数的调用链比如从系统调用入口一路追到具体的驱动实现。SI 的调用图功能能做这个但经常断链。Clangd 配合 VSCode 的调用层次视图右键菜单里的显示调用层次能比较完整地展示调用链。不过要注意Clangd 的调用层次分析是基于静态代码的对于通过函数指针调用的场景它可能追踪不到。比如file_operations里的read函数实际调用的是哪个函数取决于运行时注册的是哪个驱动。这种情况需要结合代码逻辑手动分析Clangd 只能帮你找到函数指针的赋值点。6.4 结合 IMX6ULL 硬件手册验证代码读内核代码最终要落到硬件上。IMX6ULL 的参考手册里有详细的寄存器定义和外设说明读驱动代码时对照手册看能理解代码为什么这么写。比如 GPIO 驱动里的寄存器操作对照手册的寄存器地址和位定义就能明白每一行代码的意图。我习惯在 VSCode 里开两个窗口一个放内核源码一个放硬件手册的 PDF。VSCode 有 PDF 预览插件可以直接在编辑器里看 PDF不用切来切去。读代码时遇到不确定的寄存器直接翻手册对照效率很高。7. 性能对比与长期使用体验7.1 索引速度与跳转响应实测数据我拿同一台机器i7-1070032GB 内存NVMe SSD做了对比测试。SI 4.0 全量索引 Linux 4.19.71 内核源码耗时 38 分钟索引文件大小 1.2GB。Clangd 首次索引过滤后的编译数据库耗时 6 分 20 秒索引缓存大小 480MB。后续增量索引SI 需要 5 到 10 分钟Clangd 基本在 30 秒内完成。跳转响应方面SI 在索引完成后的跳转速度很快基本是毫秒级。Clangd 首次跳转某个符号时如果该文件还没被索引到会有短暂延迟大概 1 到 2 秒之后就是毫秒级。整体体验上Clangd 的跳转准确率明显更高我统计了一下在驱动代码里随机抽 100 次跳转SI 有 23 次跳错或跳不到Clangd 只有 4 次失败而且这 4 次都是因为代码里用了非常规的宏技巧。7.2 资源占用与稳定性观察长期使用下来Clangd 的稳定性比 SI 好。SI 在索引大项目时偶尔会崩溃尤其是内存不足的时候。Clangd 作为独立进程运行即使崩溃了也不影响 VSCode重启一下就行。内存占用方面Clangd 索引完成后稳定在 1.5 到 2GBSI 大概 800MB 到 1.2GBClangd 略高但可以接受。CPU 占用方面Clangd 在后台索引时会吃满多核 CPU但可以通过-j参数限制。索引完成后CPU 占用基本为零只有在你编辑代码时才会有短暂的计算。SI 在后台会持续做一些索引维护CPU 占用虽然不高但一直有。7.3 什么情况下这套方案不适合说了这么多优点也得说说局限性。这套方案最大的门槛是需要成功编译一次内核。如果你拿到的源码编译不过或者你根本没有交叉编译工具链那就生成不了编译数据库Clangd 就发挥不出优势。这种情况下要么先解决编译问题要么退而求其次用 VSCode 的 C/C 插件配合c_cpp_properties.json手动配置头文件路径但效果会打折扣。另一个不适合的场景是只读少量文件。如果你只是偶尔看看某个驱动文件的实现不需要全局索引那直接用 VSCode 打开单个文件配合在线源码浏览网站就够了没必要折腾这套环境。还有就是机器配置太低。Clangd 索引内核源码需要至少 8GB 内存推荐 16GB 以上。如果你的机器只有 4GB 内存索引过程会非常痛苦甚至可能因为内存不足而失败。这种情况下 SI 反而是更轻量的选择。8. 我个人的使用体会与后续扩展这套环境我用了大半年从最初的磕磕绊绊到现在完全替代 SI中间踩了不少坑但整体来说是值得的。最大的感受是代码阅读的连贯性提升了。以前用 SI 读代码遇到跳转错误就得手动搜索思路经常被打断。现在 Clangd 的跳转准确率足够高可以顺着调用链一路读下去不用频繁切到搜索。另一个体会是VSCode 的生态优势。读内核代码时经常需要查资料、写笔记、对比不同版本的代码这些在 VSCode 里都能用插件搞定。比如用GitLens看代码的修改历史用Markdown Preview写阅读笔记用Remote-SSH直接连到编译服务器上操作。这些工作流整合在一起效率比在多个工具之间切换高很多。后续我打算把这套方案扩展到 U-Boot 和裸机代码的阅读上。U-Boot 的编译系统跟内核类似也是 Kbuild所以生成编译数据库的流程基本一样。裸机代码稍微麻烦一点因为没有标准的构建系统可能需要手动写compile_commands.json但工作量不大写个脚本批量生成就行。如果你也在用 IMX6ULL 或者类似的 ARM 开发板学习内核我强烈建议花半天时间把这套环境搭起来。前期投入的时间在后面读代码的过程中会加倍还回来。尤其是当你需要深入理解某个子系统的时候准确的跳转和语义补全能帮你省下大量翻代码的时间。
