第 2 章内核与用户的边界

2.1 通讯的代价

想象一下，你刚刚费尽千辛万苦把一个驱动塞进了内核空间。它工作得很完美，内部逻辑严密，数据流转顺畅——唯一的遗憾是，它像个被关在禁闭室的天才，外面的人知道它在里面，却找不到门跟它说话。

这就是我们这一章要面对的核心问题：边界。

内核空间和用户空间之间横亘着一道不可逾越的墙，这不仅是保护系统稳定的防线，也是数据流动的障碍。你的驱动再厉害，如果不能把数据交给用户空间的 App，或者接收 App 的指令，它的价值就约等于零。

这听起来像是个简单的「输入输出」问题，但当你真正动手时，你会发现这其实是个选择题。Linux 内核并没有提供一种「标准」的通信方式，而是给了你一整盒工具。每一件工具都有它的脾气，适合的场景，以及令人抓狂的副作用。

如果你随便抓过一个工具就用——比如很多人下意识会选择 ioctl，因为它听起来最像「控制」——你很快就会发现自己陷入了维护泥潭。接口定义混乱、安全性难以保证、调试时像在盲人摸象。这是因为你一开始就选错了工具，或者说，你没有理解这道「门」真正应该长什么样。

我们在这一章的任务，就是把这些工具摊开在桌面上。我们会逐一审视它们：procfs、sysfs、debugfs、netlink sockets，以及传统的 ioctl。我们会搞清楚它们为什么存在，各自的哲学是什么，以及最重要的一点——什么时候你不应该使用它们。

让我们先把目光投向那张全景地图，看看我们要到底在对比哪些方案。这不是一张简单的功能列表，而是你在架构驱动时必须做出的决策点。

如果把用户空间和内核空间看作两个需要对话的独立世界，那么摆在面前的通道大致可以分为三类：

1. 基于文件系统的接口（虚拟文件系统）

这是最符合 Linux 「一切皆文件」哲学的方案。你不需要创造新的协议，只需要在现有的文件系统挂载点下创建一个「假文件」。

procfs (/proc)：最古老的一员。最初是为了向用户空间报告进程信息而设计的，后来也被滥用于驱动接口。它像是一块告示板，适合展示简单的状态信息。
sysfs (/sys)：随着 2.6 内核引入的设备模型而来。它比 procfs 结构更严谨，严格反映内核的设备拓扑结构。如果你想控制某个具体的设备参数，这里是推荐的位置。
debugfs (/sys/kernel/debug)：这是一个专门给开发者用的「沙盒」。它对格式几乎没有限制，你可以随心所欲地丢出调试信息，而不必担心破坏系统的 ABI（应用二进制接口）。

2. 基于网络的接口（Socket 通信）

Netlink Sockets：这是一条特殊的专线。不同于文件系统的「读写」模型，Netlink 使用消息传递机制，非常适合处理异步事件。比如网卡的热插拔通知、路由表的变更，内核就是通过这种方式大声告诉用户空间的。

3. 基于设备控制的接口（传统系统调用）

Ioctl（Input/Output Control）：这是最老牌、最直接，但也最容易被滥用的方式。通过设备文件发送特定的命令码，你可以让驱动执行任何操作。强大，但也危险，因为它很容易变成一个充满魔数的黑盒。

这就引出了一个更深层的问题：我们到底在「传输」什么？

为了让你在走完这一章后能建立起这种直觉，我们接下来会针对每一种方案，编写实际的代码。我们不会只停留在理论对比上，我们会亲手实现这些接口，看它们在内核里的真实模样，甚至会故意触发几个 Kernel Panic（内核崩溃），让你亲眼看到它们脆弱的一面。