最近打开技术社区关于 Kernel 的讨论密度比往年高了不少高通 CAF Kernel、Android Kernel、WSL2 Linux Kernel Update Package、Semantic Kernel、甚至 CUDA 报错里那个 “no kernel image is available for execution”。你会发现同样都写着 Kernel彼此却几乎不是同一个东西。ARKM KERNEL approaching you soon——如果你近期看到了这个标题可能会先愣一下ARKM 是什么KERNEL 又指的是哪个内核这正是很多开发者面对“内核”时的真实状态知道它重要但一搜资料就陷入术语迷雾。有人以为是 Linux 内核有人以为是 Android 驱动还有人以为是 PyTorch 跑 GPU 时的报错。于是学了两天就放弃或者干脆在收藏夹吃灰。这篇文章既是 ARKM 内核系列的开篇也是一份可执行的内核学习路线图。我会先帮你看清“Kernel”一词在不同技术栈里的真实含义然后从零搭一套安全可控的内核实验环境带你编译加载第一个内核模块最后整理常见报错和工程建议。读完你会发现内核没有想象中那么不可碰但确实需要一套正确的打开方式。1. 内核不止一个先分清你遇到的是哪个 Kernel很多开发者学内核学不下去不是能力问题而是定位问题。他看到的“Kernel”根本不是同一个对象。名称所属领域它到底是什么开发者通常怎么接触它Linux Kernel操作系统管理进程、内存、文件、设备的核心程序编译内核、加载驱动、排查系统负载Android Kernel / CAF Kernel移动终端基于 Linux 的 Android 系统内核CAF 是高通平台代码分支刷机、内核移植、功耗调优、SELinuxCUDA KernelGPU 并行计算在 GPU 上执行的并行函数不是操作系统PyTorch/TensorFlow 训练时报错时看到Semantic KernelAI 应用开发微软的 AI 编排 SDK和操作系统无关写 Agent、编排 LLM 提示词时使用WSL2 KernelWindows 子系统微软为 WSL2 定制的 Linux 内核在 Windows 下做 Linux 开发、容器实验Vivado Simulator KernelFPGA/EDA硬件仿真引擎的内核调度部分用 Vivado 做芯片逻辑仿真时出现可以发现“Kernel”在不同语境下承担着完全不同的职责。在操作系统里Kernel 是系统的心脏负责 CPU、内存、设备资源分配。在 GPU 编程里Kernel 是跑在显卡上的一个并行函数。在 AI 开发里Semantic Kernel 只是名字里带 Kernel 的 SDK。在 WSL2 里它是让你在 Windows 中运行 Linux 二进制程序的底层支撑。ARKM 系列要讲的是操作系统内核这一层重点覆盖 Linux Kernel、Android Kernel/CAF Kernel以及内核开发调试的通用方法。至于 CUDA Kernel 报错、Semantic Kernel 这类同名概念只做对照区分不会展开成主线。这样定位之后下面的内容才有统一的坐标系。2. 为什么内核值得学ARKM 系列的定位先回答一个很实际的问题我只是写业务代码有必要碰内核吗我的判断是如果你只做纯业务 CRUD确实可以不学但只要你开始关注性能、稳定性、并发、容器或 AI 训练环境问题内核就是你绕不开的最后一层。几个真实场景后端服务在高并发下出现长尾延迟排查到最后发现是上下文切换频繁、CPU 调度策略不合理。Android 应用卡顿优化到应用层已经没空间需要看 binder 调用、内核 CPU 调频策略。PyTorch 在 GPU 上训练报CUDA error: no kernel image is available for execution本质是 CUDA 运行环境与 GPU 硬件、驱动之间的兼容问题。Docker 容器资源隔离上限不生效原因是 cgroup 配置或内核特性未开启。WSL2 里想加载自定义内核模块发现 Windows Update 提供的内核并不允许随意 insmod。这些问题的答案几乎都在内核层面。ARKM 系列定位也来自这里不追所谓的新概念而是沿着“理解内核机制 → 亲手编译内核 → 编写模块/驱动 → 性能分析与安全加固”这条路径把内核开发变成可验证、可复现的工程实践。适合阅读的人群包括后端开发者想深入理解进程、内存、IO 与容器隔离。Android 开发者需要接触 ROM 开发、内核移植或性能调优。嵌入式开发者需要为特定硬件编译内核。性能工程与 SRE需要读懂内核指标定位系统瓶颈。对系统安全感兴趣想理解内核漏洞影响的开发者。如果你只是打算读完这篇文章就去面经里背几个概念那效果会非常有限。内核学习的核心动作是动手不是阅读。3. 理解内核运行的基本原理用户态、内核态与模块化在写第一个内核模块之前有必要把内核最基本的运行模型说清楚。3.1 用户态与内核态操作系统把 CPU 的运行级别分成至少两层用户态应用程序运行的地方。权限受限直接访问硬件会被拒绝。内核态内核代码运行的地方。可以执行特权指令访问全部内存和设备。当你调用read()、write()、malloc()这类接口时实际发生的是用户态程序通过系统调用陷入内核态由内核完成真正的资源操作后再返回。这层隔离是操作系统的安全基础。用户程序崩溃最多是一个进程退出内核崩溃整个系统直接挂了。这一事实决定了内核开发方式的特殊性不能像调试普通程序一样在 IDE 里打断点而是在虚拟机或虚拟机化环境里反复试错。3.2 Linux 的模块化机制现代 Linux 内核不是一坨完整的静态程序而是支持动态加载模块的架构。模块Module是一段可以被内核在运行时加载和卸载的代码最常见的形式就是设备驱动。模块机制的出现让内核开发的学习门槛大幅下降不需要每次改一行代码就重新编译整个内核。不需要为了试驱动就重启系统。可以按需加载文件系统、网络协议、设备驱动等功能。你今天的第一个实验就是写一个最小的内核模块让它在内核空间打印一条消息。3.3 为什么我建议你在虚拟机或 WSL2 里学习既然内核崩溃会导致整个系统崩溃学习阶段就不要拿物理机开玩笑。推荐方案优先级WSL2Windows 用户最方便隔离性较好可直接使用apt安装内核头文件。虚拟机VirtualBox / QEMU / VMwaremacOS 和 Windows 都适用快照功能可以随时回滚。云服务器适合编译场景但千万别在生产环境实例上乱加载模块。物理机不推荐新手用来学习除非你知道自己在做什么并有 Live CD/备份方案。从安全底线出发内核开发环境必须可控、可回滚、不影响生产业务。4. 环境准备搭建一个安全可控的内核实验环境现在开始动手。本系列的环境以 Linux 为主Windows 用户建议先启用 WSL2。4.1 Windows 用户启用 WSL2 并更新内核在 Windows PowerShell管理员中执行wsl --install安装完成并重启后打开 WSL2 终端确认发行版和内核版本uname -r如果你使用的是较旧的 WSL2可能还需要手动安装“WSL2 Linux 内核更新包”。这个更新包是微软发布的独立安装程序会替换掉 WSL2 默认内核。从实践看新装 WSL2 后第一件事就是把内核更新到最新否则后续编译模块时可能遇到版本不一致问题。需要注意WSL2 默认内核是微软定制内核。学习阶段直接编译模块在 WSL2 中可能遇到模块签名或内核配置限制所以更稳妥的做法是在 WSL2 里使用 Ubuntu 官方内核版本来做模块实验或者直接用虚拟机。4.2 Linux 环境准备我以 Ubuntu/Debian 为例在 WSL2 或虚拟机中执行sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) kmod这组包的作用build-essential提供 gcc、make 等编译工具。linux-headers-$(uname -r)与当前内核版本匹配的头文件编译内核模块必须依赖它。kmod提供insmod、rmmod、modprobe等模块管理工具。验证头文件已经安装ls /usr/src/linux-headers-$(uname -r)如果这个目录不存在说明 headers 包没装上或者内核版本名与包名对不上。这是后续一切编译问题的最常见来源。4.3 确认内核版本与编译工具uname -r gcc --version make --version记下当前内核版本后面模块编译时必须使用同一个版本的头文件。这里我不写死具体版本号是因为不同环境差异很大。版本以你实际环境的uname -r为准这是内核开发的第一原则头文件必须匹配当前运行内核。5. 第一个内核模块hello_kernel 完整实现完成了环境准备我们来写第一个内核模块。这个模块本身没有实用功能但它能帮你跑通“编写 → 编译 → 加载 → 验证 → 卸载”的完整流程。5.1 项目结构建议在工作目录下新建arkm-hello-kernel文件夹例如在 WSL2 的~/projects/arkm-hello-kernel里面放两个文件。5.2 模块源码文件路径arkm-hello-kernel/hello_kernel.c#include linux/init.h #include linux/module.h #include linux/kernel.h MODULE_LICENSE(GPL); MODULE_AUTHOR(ARKM Project); MODULE_DESCRIPTION(A simple hello kernel module for ARKM series); MODULE_VERSION(0.1); static int __init hello_kernel_init(void) { printk(KERN_INFO arkm: hello_kernel module loaded\n); return 0; } static void __exit hello_kernel_exit(void) { printk(KERN_INFO arkm: hello_kernel module unloaded\n); } module_init(hello_kernel_init); module_exit(hello_kernel_exit);关键点解析#include linux/init.h和linux/module.h是内核模块最基本的头文件前者包含加载/卸载函数相关宏后者包含模块定义的宏。MODULE_LICENSE(GPL)声明许可证。内核模块如果不声明 GPL某些 GPL 导出的内核符号将无法使用。__init、__exit是内核属性宏。__init函数在模块加载完成后所占内存可以被释放__exit在模块编译进内核时会被丢弃。printk是内核态打印函数和用户态的printf不同它输出到内核日志需要用dmesg查看。module_init()和module_exit()把函数注册为模块的入口和出口。5.3 Makefile文件路径arkm-hello-kernel/Makefileobj-m hello_kernel.o KDIR : /lib/modules/$(shell uname -r)/build all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean逐行解释obj-m hello_kernel.o告诉内核构建系统把hello_kernel.c编译成可加载模块。KDIR指向当前内核的构建目录/lib/modules/$(uname -r)/build是一个符号链接指向对应的内核头文件目录。all目标调用内核构建系统编译当前目录下的模块。clean目标清理编译产物。这是内核模块开发最标准的 Makefile 写法。以后你的模块文件变了只需要改obj-m那一行。5.4 编译模块在arkm-hello-kernel目录下执行make如果一切正常你会看到编译输出并生成以下文件hello_kernel.ko hello_kernel.mod.c hello_kernel.mod.o hello_kernel.o其中hello_kernel.ko就是最终的内核模块文件。6. 运行结果与效果验证编译通过只是第一步真正的验证是让这个模块成功加载到内核中。6.1 加载模块sudo insmod hello_kernel.ko如果没有输出说明加载可能成功了。内核模块加载成功时默认不打印到终端而是写入内核日志。查看内核日志dmesg | tail -20预期输出里会出现arkm: hello_kernel module loaded看到这一行说明你的第一个内核模块已经成功运行在内核态了。6.2 确认模块已加载lsmod | grep hello_kernel预期输出包含hello_kernel 16384 0第三列数字表示当前有多少进程/模块在使用它0说明暂时没有被依赖。6.3 卸载模块sudo rmmod hello_kernel再查看日志dmesg | tail -20预期多出一行arkm: hello_kernel module unloaded6.4 判断标准insmod没有报错。lsmod能看到模块。dmesg能看到加载和卸载日志。如果这三步都完成你的内核模块开发流程已经跑通。整个流程中系统没有重启也没有影响正在运行的进程这正是模块机制的威力。7. 常见问题与排查思路内核模块开发最容易踩的坑集中在版本不匹配、权限不足和内核签名三块。下面整理成排查表。问题现象可能原因排查方式解决方案编译报错找不到linux/init.h未安装内核头文件ls /usr/src/linux-headers-$(uname -r)安装linux-headers-$(uname -r)make后提示版本 magic 不匹配头文件版本与当前内核版本不一致uname -r对比头文件目录名更新头文件包重启后重试insmod报错Operation not permitted权限不足确认命令前是否加了sudo使用sudo insmod或检查内核配置insmod报错module verification failed内核开启了强制模块签名校验cat /sys/module/*/taint查看 tainted 状态编译模块时生成签名密钥或在开发环境关闭签名校验WSL2 自定义内核后模块加载失败WSL2 内核与 Ubuntu 发行版内核不一致uname -r对比/lib/modules目录在 WSL2 内安装与当前内核匹配的 headers加载后系统日志没有任何printk输出日志级别过滤或 console 未显示dmesg -n 8提高日志级别使用 dmesg还有一个容易让人困惑的情况insmod成功但马上rmmod后模块没有打印 unload 日志。这通常是因为 printk 日志级别低于当前 console 显示级别日志被过滤了。用dmesg | grep arkm基本都能看到。遇到问题时第一件事永远是看内核日志不是猜。内核日志位于dmesg或/var/log/kern.log这是内核开发最基础也最重要的排错入口。另外前面热词里提到的torch.acceleratorerror: cuda error: no kernel image is available for execution虽然也叫 kernel但属于 CUDA 领域它表示当前 PyTorch 版本编译的 CUDA kernel 与你的 GPU 算力不匹配。排查方向是检查 GPU 算力、CUDA 版本、PyTorch 对应关系。操作系统内核排错的思路与它完全不同这再次印证了先分清 Kernel 语境的重要性。8. 最佳实践与工程建议跑通“第一个模块”只是起点。要把内核开发当成工程来做下面这些建议会帮你少走很多弯路。8.1 学习阶段必须建立隔离环境在内核学习阶段虚拟机快照是最值得信任的回滚手段。每次做实验前保存快照系统崩溃后直接恢复不用重装环境。WSL2 也是不错的选择但注意WSL2 内核是微软定制内核部分内核配置可能与主线不同。如果模块加载涉及 GPIO、I2C 等硬件操作WSL2 无法真实访问硬件需要换到虚拟机或开发板。8.2 版本匹配原则内核模块必须和正在运行的内核版本、头文件版本完全匹配。升级内核、更换内核后之前编译的内核模块全部需要重新编译。这条原则在生产环境同样成立Linux 内核从 5.x 升到 6.x第三方驱动必须验证兼容性不能假设二进制可以直接复用。8.3 模块签名与 Secure Boot现代 Linux 发行版默认开启 Secure Boot 时会要求内核模块经过签名验证。未签名模块加载时会报module verification failed。对学习环境可以直接在虚拟机里关闭 Secure Boot。对生产环境则应该走完整的模块签名流程或者避免使用第三方自编模块优先使用发行版仓库内的驱动包。8.4 日志与性能分析工具printk最基础的调试方式适合入门但 printk 过多会影响性能。ftrace内核动态追踪工具用于追踪函数调用。perf性能分析查看 CPU 事件、函数热点。kgdb内核调试器配合 QEMU 或物理串口使用。bpftrace基于 eBPF 的动态追踪工具生产环境排查利器。从工程角度生产环境不建议直接用printk做详细调试而是通过 tracepoint、perf、eBPF 等方式做观测。这样对系统行为的影响更小。8.5 安全与权限边界内核漏洞的影响面远大于普通应用漏洞。内核代码运行在最高特权级别一旦被利用可能直接获取整个系统控制权。因此不要在生产环境随意加载来源不明的内核模块。及时跟进发行版内核安全补丁。对内核模块实施签名验证。内核模块应遵守最小权限原则不做超出自身功能的操作。涉及生产环境的内核变更必须有完整的变更评审、灰度验证和回滚方案。8.6 代码规范内核模块代码遵循 Linux kernel coding style尤其是缩进使用 Tab不是空格。函数命名使用小写加下划线。注释风格使用/* ... */。变量声明不要和语句混在一起。提交上游 patch 之前可以用checkpatch.pl检查代码风格/usr/src/linux-headers-$(uname -r)/scripts/checkpatch.pl --no-tree hello_kernel.c8.7 版本管理即使只是学习也建议用 Git 管理模块代码。每个模块一个分支或 tag写清楚适配的内核版本。很多线上问题最终都能追溯到“代码没有记录它依赖的内核版本”。9. 下一步ARKM 系列会做什么以及你可以从哪继续这篇文章把内核学习最重要的一小步走完了理解了 Kernel 的多种含义搭好了实验环境编译并验证了第一个内核模块。但这仅仅是一个开始。ARKM 系列后续会沿着下面这些主题展开主线内核的编译与定制理解内核配置项。字符设备驱动开发写一个真正的可读写设备。Android Kernel 与高通 CAF Kernel 的联系与区别。基于 eBPF 的内核观测与性能分析。内核安全基础漏洞影响范围、加固思路。内核模块签名、发布与生产环境落地流程。如果你想保持学习节奏现在就可以做三件事把hello_kernel模块改成打印当前进程 PID重新编译加载观察日志变化。在虚拟机里编译一次完整主线内核感受内核编译的全过程。阅读/usr/src/linux-headers-$(uname -r)/Documentation下的模块相关文档。内核的难点从来不是语法而是问题域的变化你不再拥有用户态那种“挂了重启进程就行”的容错空间每个操作都直接影响整个系统。这种变化会让习惯应用开发的开发者非常不适应但也正是它如此有学习价值的原因。先把环境准备好把第一个模块跑通。剩下的交给持续练习和时间。
内核入门指南：分清Kernel概念，动手编译第一个Linux内核模块
最近打开技术社区关于 Kernel 的讨论密度比往年高了不少高通 CAF Kernel、Android Kernel、WSL2 Linux Kernel Update Package、Semantic Kernel、甚至 CUDA 报错里那个 “no kernel image is available for execution”。你会发现同样都写着 Kernel彼此却几乎不是同一个东西。ARKM KERNEL approaching you soon——如果你近期看到了这个标题可能会先愣一下ARKM 是什么KERNEL 又指的是哪个内核这正是很多开发者面对“内核”时的真实状态知道它重要但一搜资料就陷入术语迷雾。有人以为是 Linux 内核有人以为是 Android 驱动还有人以为是 PyTorch 跑 GPU 时的报错。于是学了两天就放弃或者干脆在收藏夹吃灰。这篇文章既是 ARKM 内核系列的开篇也是一份可执行的内核学习路线图。我会先帮你看清“Kernel”一词在不同技术栈里的真实含义然后从零搭一套安全可控的内核实验环境带你编译加载第一个内核模块最后整理常见报错和工程建议。读完你会发现内核没有想象中那么不可碰但确实需要一套正确的打开方式。1. 内核不止一个先分清你遇到的是哪个 Kernel很多开发者学内核学不下去不是能力问题而是定位问题。他看到的“Kernel”根本不是同一个对象。名称所属领域它到底是什么开发者通常怎么接触它Linux Kernel操作系统管理进程、内存、文件、设备的核心程序编译内核、加载驱动、排查系统负载Android Kernel / CAF Kernel移动终端基于 Linux 的 Android 系统内核CAF 是高通平台代码分支刷机、内核移植、功耗调优、SELinuxCUDA KernelGPU 并行计算在 GPU 上执行的并行函数不是操作系统PyTorch/TensorFlow 训练时报错时看到Semantic KernelAI 应用开发微软的 AI 编排 SDK和操作系统无关写 Agent、编排 LLM 提示词时使用WSL2 KernelWindows 子系统微软为 WSL2 定制的 Linux 内核在 Windows 下做 Linux 开发、容器实验Vivado Simulator KernelFPGA/EDA硬件仿真引擎的内核调度部分用 Vivado 做芯片逻辑仿真时出现可以发现“Kernel”在不同语境下承担着完全不同的职责。在操作系统里Kernel 是系统的心脏负责 CPU、内存、设备资源分配。在 GPU 编程里Kernel 是跑在显卡上的一个并行函数。在 AI 开发里Semantic Kernel 只是名字里带 Kernel 的 SDK。在 WSL2 里它是让你在 Windows 中运行 Linux 二进制程序的底层支撑。ARKM 系列要讲的是操作系统内核这一层重点覆盖 Linux Kernel、Android Kernel/CAF Kernel以及内核开发调试的通用方法。至于 CUDA Kernel 报错、Semantic Kernel 这类同名概念只做对照区分不会展开成主线。这样定位之后下面的内容才有统一的坐标系。2. 为什么内核值得学ARKM 系列的定位先回答一个很实际的问题我只是写业务代码有必要碰内核吗我的判断是如果你只做纯业务 CRUD确实可以不学但只要你开始关注性能、稳定性、并发、容器或 AI 训练环境问题内核就是你绕不开的最后一层。几个真实场景后端服务在高并发下出现长尾延迟排查到最后发现是上下文切换频繁、CPU 调度策略不合理。Android 应用卡顿优化到应用层已经没空间需要看 binder 调用、内核 CPU 调频策略。PyTorch 在 GPU 上训练报CUDA error: no kernel image is available for execution本质是 CUDA 运行环境与 GPU 硬件、驱动之间的兼容问题。Docker 容器资源隔离上限不生效原因是 cgroup 配置或内核特性未开启。WSL2 里想加载自定义内核模块发现 Windows Update 提供的内核并不允许随意 insmod。这些问题的答案几乎都在内核层面。ARKM 系列定位也来自这里不追所谓的新概念而是沿着“理解内核机制 → 亲手编译内核 → 编写模块/驱动 → 性能分析与安全加固”这条路径把内核开发变成可验证、可复现的工程实践。适合阅读的人群包括后端开发者想深入理解进程、内存、IO 与容器隔离。Android 开发者需要接触 ROM 开发、内核移植或性能调优。嵌入式开发者需要为特定硬件编译内核。性能工程与 SRE需要读懂内核指标定位系统瓶颈。对系统安全感兴趣想理解内核漏洞影响的开发者。如果你只是打算读完这篇文章就去面经里背几个概念那效果会非常有限。内核学习的核心动作是动手不是阅读。3. 理解内核运行的基本原理用户态、内核态与模块化在写第一个内核模块之前有必要把内核最基本的运行模型说清楚。3.1 用户态与内核态操作系统把 CPU 的运行级别分成至少两层用户态应用程序运行的地方。权限受限直接访问硬件会被拒绝。内核态内核代码运行的地方。可以执行特权指令访问全部内存和设备。当你调用read()、write()、malloc()这类接口时实际发生的是用户态程序通过系统调用陷入内核态由内核完成真正的资源操作后再返回。这层隔离是操作系统的安全基础。用户程序崩溃最多是一个进程退出内核崩溃整个系统直接挂了。这一事实决定了内核开发方式的特殊性不能像调试普通程序一样在 IDE 里打断点而是在虚拟机或虚拟机化环境里反复试错。3.2 Linux 的模块化机制现代 Linux 内核不是一坨完整的静态程序而是支持动态加载模块的架构。模块Module是一段可以被内核在运行时加载和卸载的代码最常见的形式就是设备驱动。模块机制的出现让内核开发的学习门槛大幅下降不需要每次改一行代码就重新编译整个内核。不需要为了试驱动就重启系统。可以按需加载文件系统、网络协议、设备驱动等功能。你今天的第一个实验就是写一个最小的内核模块让它在内核空间打印一条消息。3.3 为什么我建议你在虚拟机或 WSL2 里学习既然内核崩溃会导致整个系统崩溃学习阶段就不要拿物理机开玩笑。推荐方案优先级WSL2Windows 用户最方便隔离性较好可直接使用apt安装内核头文件。虚拟机VirtualBox / QEMU / VMwaremacOS 和 Windows 都适用快照功能可以随时回滚。云服务器适合编译场景但千万别在生产环境实例上乱加载模块。物理机不推荐新手用来学习除非你知道自己在做什么并有 Live CD/备份方案。从安全底线出发内核开发环境必须可控、可回滚、不影响生产业务。4. 环境准备搭建一个安全可控的内核实验环境现在开始动手。本系列的环境以 Linux 为主Windows 用户建议先启用 WSL2。4.1 Windows 用户启用 WSL2 并更新内核在 Windows PowerShell管理员中执行wsl --install安装完成并重启后打开 WSL2 终端确认发行版和内核版本uname -r如果你使用的是较旧的 WSL2可能还需要手动安装“WSL2 Linux 内核更新包”。这个更新包是微软发布的独立安装程序会替换掉 WSL2 默认内核。从实践看新装 WSL2 后第一件事就是把内核更新到最新否则后续编译模块时可能遇到版本不一致问题。需要注意WSL2 默认内核是微软定制内核。学习阶段直接编译模块在 WSL2 中可能遇到模块签名或内核配置限制所以更稳妥的做法是在 WSL2 里使用 Ubuntu 官方内核版本来做模块实验或者直接用虚拟机。4.2 Linux 环境准备我以 Ubuntu/Debian 为例在 WSL2 或虚拟机中执行sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) kmod这组包的作用build-essential提供 gcc、make 等编译工具。linux-headers-$(uname -r)与当前内核版本匹配的头文件编译内核模块必须依赖它。kmod提供insmod、rmmod、modprobe等模块管理工具。验证头文件已经安装ls /usr/src/linux-headers-$(uname -r)如果这个目录不存在说明 headers 包没装上或者内核版本名与包名对不上。这是后续一切编译问题的最常见来源。4.3 确认内核版本与编译工具uname -r gcc --version make --version记下当前内核版本后面模块编译时必须使用同一个版本的头文件。这里我不写死具体版本号是因为不同环境差异很大。版本以你实际环境的uname -r为准这是内核开发的第一原则头文件必须匹配当前运行内核。5. 第一个内核模块hello_kernel 完整实现完成了环境准备我们来写第一个内核模块。这个模块本身没有实用功能但它能帮你跑通“编写 → 编译 → 加载 → 验证 → 卸载”的完整流程。5.1 项目结构建议在工作目录下新建arkm-hello-kernel文件夹例如在 WSL2 的~/projects/arkm-hello-kernel里面放两个文件。5.2 模块源码文件路径arkm-hello-kernel/hello_kernel.c#include linux/init.h #include linux/module.h #include linux/kernel.h MODULE_LICENSE(GPL); MODULE_AUTHOR(ARKM Project); MODULE_DESCRIPTION(A simple hello kernel module for ARKM series); MODULE_VERSION(0.1); static int __init hello_kernel_init(void) { printk(KERN_INFO arkm: hello_kernel module loaded\n); return 0; } static void __exit hello_kernel_exit(void) { printk(KERN_INFO arkm: hello_kernel module unloaded\n); } module_init(hello_kernel_init); module_exit(hello_kernel_exit);关键点解析#include linux/init.h和linux/module.h是内核模块最基本的头文件前者包含加载/卸载函数相关宏后者包含模块定义的宏。MODULE_LICENSE(GPL)声明许可证。内核模块如果不声明 GPL某些 GPL 导出的内核符号将无法使用。__init、__exit是内核属性宏。__init函数在模块加载完成后所占内存可以被释放__exit在模块编译进内核时会被丢弃。printk是内核态打印函数和用户态的printf不同它输出到内核日志需要用dmesg查看。module_init()和module_exit()把函数注册为模块的入口和出口。5.3 Makefile文件路径arkm-hello-kernel/Makefileobj-m hello_kernel.o KDIR : /lib/modules/$(shell uname -r)/build all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean逐行解释obj-m hello_kernel.o告诉内核构建系统把hello_kernel.c编译成可加载模块。KDIR指向当前内核的构建目录/lib/modules/$(uname -r)/build是一个符号链接指向对应的内核头文件目录。all目标调用内核构建系统编译当前目录下的模块。clean目标清理编译产物。这是内核模块开发最标准的 Makefile 写法。以后你的模块文件变了只需要改obj-m那一行。5.4 编译模块在arkm-hello-kernel目录下执行make如果一切正常你会看到编译输出并生成以下文件hello_kernel.ko hello_kernel.mod.c hello_kernel.mod.o hello_kernel.o其中hello_kernel.ko就是最终的内核模块文件。6. 运行结果与效果验证编译通过只是第一步真正的验证是让这个模块成功加载到内核中。6.1 加载模块sudo insmod hello_kernel.ko如果没有输出说明加载可能成功了。内核模块加载成功时默认不打印到终端而是写入内核日志。查看内核日志dmesg | tail -20预期输出里会出现arkm: hello_kernel module loaded看到这一行说明你的第一个内核模块已经成功运行在内核态了。6.2 确认模块已加载lsmod | grep hello_kernel预期输出包含hello_kernel 16384 0第三列数字表示当前有多少进程/模块在使用它0说明暂时没有被依赖。6.3 卸载模块sudo rmmod hello_kernel再查看日志dmesg | tail -20预期多出一行arkm: hello_kernel module unloaded6.4 判断标准insmod没有报错。lsmod能看到模块。dmesg能看到加载和卸载日志。如果这三步都完成你的内核模块开发流程已经跑通。整个流程中系统没有重启也没有影响正在运行的进程这正是模块机制的威力。7. 常见问题与排查思路内核模块开发最容易踩的坑集中在版本不匹配、权限不足和内核签名三块。下面整理成排查表。问题现象可能原因排查方式解决方案编译报错找不到linux/init.h未安装内核头文件ls /usr/src/linux-headers-$(uname -r)安装linux-headers-$(uname -r)make后提示版本 magic 不匹配头文件版本与当前内核版本不一致uname -r对比头文件目录名更新头文件包重启后重试insmod报错Operation not permitted权限不足确认命令前是否加了sudo使用sudo insmod或检查内核配置insmod报错module verification failed内核开启了强制模块签名校验cat /sys/module/*/taint查看 tainted 状态编译模块时生成签名密钥或在开发环境关闭签名校验WSL2 自定义内核后模块加载失败WSL2 内核与 Ubuntu 发行版内核不一致uname -r对比/lib/modules目录在 WSL2 内安装与当前内核匹配的 headers加载后系统日志没有任何printk输出日志级别过滤或 console 未显示dmesg -n 8提高日志级别使用 dmesg还有一个容易让人困惑的情况insmod成功但马上rmmod后模块没有打印 unload 日志。这通常是因为 printk 日志级别低于当前 console 显示级别日志被过滤了。用dmesg | grep arkm基本都能看到。遇到问题时第一件事永远是看内核日志不是猜。内核日志位于dmesg或/var/log/kern.log这是内核开发最基础也最重要的排错入口。另外前面热词里提到的torch.acceleratorerror: cuda error: no kernel image is available for execution虽然也叫 kernel但属于 CUDA 领域它表示当前 PyTorch 版本编译的 CUDA kernel 与你的 GPU 算力不匹配。排查方向是检查 GPU 算力、CUDA 版本、PyTorch 对应关系。操作系统内核排错的思路与它完全不同这再次印证了先分清 Kernel 语境的重要性。8. 最佳实践与工程建议跑通“第一个模块”只是起点。要把内核开发当成工程来做下面这些建议会帮你少走很多弯路。8.1 学习阶段必须建立隔离环境在内核学习阶段虚拟机快照是最值得信任的回滚手段。每次做实验前保存快照系统崩溃后直接恢复不用重装环境。WSL2 也是不错的选择但注意WSL2 内核是微软定制内核部分内核配置可能与主线不同。如果模块加载涉及 GPIO、I2C 等硬件操作WSL2 无法真实访问硬件需要换到虚拟机或开发板。8.2 版本匹配原则内核模块必须和正在运行的内核版本、头文件版本完全匹配。升级内核、更换内核后之前编译的内核模块全部需要重新编译。这条原则在生产环境同样成立Linux 内核从 5.x 升到 6.x第三方驱动必须验证兼容性不能假设二进制可以直接复用。8.3 模块签名与 Secure Boot现代 Linux 发行版默认开启 Secure Boot 时会要求内核模块经过签名验证。未签名模块加载时会报module verification failed。对学习环境可以直接在虚拟机里关闭 Secure Boot。对生产环境则应该走完整的模块签名流程或者避免使用第三方自编模块优先使用发行版仓库内的驱动包。8.4 日志与性能分析工具printk最基础的调试方式适合入门但 printk 过多会影响性能。ftrace内核动态追踪工具用于追踪函数调用。perf性能分析查看 CPU 事件、函数热点。kgdb内核调试器配合 QEMU 或物理串口使用。bpftrace基于 eBPF 的动态追踪工具生产环境排查利器。从工程角度生产环境不建议直接用printk做详细调试而是通过 tracepoint、perf、eBPF 等方式做观测。这样对系统行为的影响更小。8.5 安全与权限边界内核漏洞的影响面远大于普通应用漏洞。内核代码运行在最高特权级别一旦被利用可能直接获取整个系统控制权。因此不要在生产环境随意加载来源不明的内核模块。及时跟进发行版内核安全补丁。对内核模块实施签名验证。内核模块应遵守最小权限原则不做超出自身功能的操作。涉及生产环境的内核变更必须有完整的变更评审、灰度验证和回滚方案。8.6 代码规范内核模块代码遵循 Linux kernel coding style尤其是缩进使用 Tab不是空格。函数命名使用小写加下划线。注释风格使用/* ... */。变量声明不要和语句混在一起。提交上游 patch 之前可以用checkpatch.pl检查代码风格/usr/src/linux-headers-$(uname -r)/scripts/checkpatch.pl --no-tree hello_kernel.c8.7 版本管理即使只是学习也建议用 Git 管理模块代码。每个模块一个分支或 tag写清楚适配的内核版本。很多线上问题最终都能追溯到“代码没有记录它依赖的内核版本”。9. 下一步ARKM 系列会做什么以及你可以从哪继续这篇文章把内核学习最重要的一小步走完了理解了 Kernel 的多种含义搭好了实验环境编译并验证了第一个内核模块。但这仅仅是一个开始。ARKM 系列后续会沿着下面这些主题展开主线内核的编译与定制理解内核配置项。字符设备驱动开发写一个真正的可读写设备。Android Kernel 与高通 CAF Kernel 的联系与区别。基于 eBPF 的内核观测与性能分析。内核安全基础漏洞影响范围、加固思路。内核模块签名、发布与生产环境落地流程。如果你想保持学习节奏现在就可以做三件事把hello_kernel模块改成打印当前进程 PID重新编译加载观察日志变化。在虚拟机里编译一次完整主线内核感受内核编译的全过程。阅读/usr/src/linux-headers-$(uname -r)/Documentation下的模块相关文档。内核的难点从来不是语法而是问题域的变化你不再拥有用户态那种“挂了重启进程就行”的容错空间每个操作都直接影响整个系统。这种变化会让习惯应用开发的开发者非常不适应但也正是它如此有学习价值的原因。先把环境准备好把第一个模块跑通。剩下的交给持续练习和时间。