【简单硬件】从一行代码到硬件寄存器:Linux I/O 的完整旅程

【简单硬件】从一行代码到硬件寄存器：Linux I/O 的完整旅程

你有没有想过，当你在程序里写下：

1
2
3
4

int fd = open("/dev/i2c-1", O_RDWR);
ioctl(fd, I2C_SLAVE, 0x48); // 设置从机地址
write(fd, &reg_addr, 1);
read(fd, &temp_data, 2);

这短短几行代码，背后究竟发生了什么？

更关键的是——如果你要接入一个全新的温度传感器，比如 BMP280，你需要改哪些代码？哪些可以直接复用？

今天，我们就沿着 Linux I/O 路径，一层层拆解，并重点回答这个工程问题。

回顾：Linux I/O 的六层架构

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

[ 用户空间 ]
│
├── 1. 应用程序（Python / C / Shell）
│       │
│       └── 调用 POSIX API（如 open(), read(), write(), ioctl()）
│
├── 2. C 标准库（glibc / musl）
│       │
│       └── 封装系统调用（如 __open() → syscall(SYS_openat)）
│
└── [ 内核空间 ]
        │
        ├── 3. 系统调用入口（syscall handler）
        │
        ├── 4. VFS（Virtual File System）
        │       │
        │       └── 抽象文件操作（file_operations）
        │
        ├── 5. 具体文件系统或设备驱动
        │       │
        │       ├── 字符设备：如 i2c-dev、spidev、tty 驱动
        │       ├── 块设备：如 ext4、sd 驱动
        │       └── 网络设备：如 netdev（不走 VFS）
        │
        └── 6. 硬件（寄存器/MMIO/中断/DMA）

现在，我们以 新增一个 I²C 接口的 BMP280 气压传感器为例，逐层分析：

✅ 用户空间（应用程序 + C 库）：通常 不需要修改

• • 原因：Linux 提供了通用的用户态 I/O 接口。
• • 示例：
• • 对于 I²C 设备，可直接使用 /dev/i2c-N + ioctl(I2C_SLAVE)；
• • 对于 SPI，可用 /dev/spidevB.C；
• • 这些接口由内核的 i2c-dev.c 和 spidev.c 驱动提供，属于“通用字符设备驱动”。

✅ 结论：只要你的传感器走标准总线（I²C/SPI/UART），应用层完全无需改动。你只需写一个用户态工具读写寄存器即可。

⚠️ 例外：若追求极致性能或需要内核级事件触发（如中断上报），才考虑写专用驱动。

✅ C 标准库 & 系统调用入口：绝对不需要改

• • glibc、musl 是通用运行时库；
• • 系统调用表是内核基础设施；
• • 它们对所有设备一视同仁。

✅ 结论：这两层是“操作系统基石”，新增传感器 零影响。

✅ VFS 层：不需要修改

• • VFS 只负责路径解析和分发；
• • 只要设备节点（如 /dev/i2c-1）存在，VFS 就能正确路由到对应的驱动（i2c-dev）；
• • 你新增的传感器只是“另一个 I²C 从设备”，对 VFS 透明。

✅ 结论：VFS 是“交通警察”，只管指路，不管车上拉的是土豆还是芯片。

🔧 设备驱动层：可能需要修改，也可能不需要！

这是最关键的判断点。分两种情况：

情况一：使用 通用用户态驱动（i2c-dev / spidev）

• • 无需写新驱动；
• • 在设备树（Device Tree）或 ACPI 中声明 I²C 设备即可；
• • 用户空间直接通过 /dev/i2c-1 访问。

✅ 适用场景：调试、原型开发、低频采样（如每秒读一次温度）。

1
2
3
4
5
6
7
8

// arch/arm64/boot/dts/your-board.dts
&i2c1 {
    status = "okay";
    bmp280: bmp280@76 {
        compatible = "bosch,bmp280";
        reg = <0x76>;
    };
};

📌 注意：即使没写专用驱动，设备树中声明设备仍有助于 udev 自动创建符号链接（如 /dev/bmp280）。

情况二：编写 专用内核驱动

• • 需要实现 struct i2c_driver；
• • 注册 .probe() 函数，绑定设备树 compatible；
• • 实现 sysfs 接口（如 /sys/bus/i2c/devices/1-0076/temp）；
• • 可能集成进 hwmon、iio 子系统（工业标准）。

✅ 适用场景：

• • 高频采样（如 IMU 传感器 1kHz）；
• • 需要中断唤醒（如跌落检测）；
• • 需要与其他内核模块交互（如 thermal framework）；
• • 产品化要求统一接口。

🔧 此时你需要修改：

• • 新增驱动源码（如 drivers/iio/pressure/bmp280.c）；
• • 修改 Kconfig 和 Makefile；
• • 更新设备树 compatible 字段。

🔧 硬件抽象层（SoC 级）：通常不需要改，除非新总线

• • 如果你的平台已有 I²C 控制器驱动（如 i2c-imx.c、i2c-designware.c），直接复用；
• • 只有当你使用 全新类型的总线（比如自定义 SPI+GPIO 模拟），才需写新的 bus driver。

✅ 结论：99% 的商用 SoC（如 Raspberry Pi、NXP i.MX、Rockchip）已支持标准总线，无需动底层控制器驱动。

🎯 总结：新增传感器，到底要改哪里？

💡 工程建议：如何选择？

• • 快速验证？ → 用 i2cget / i2cdump + /dev/i2c-N，零代码；
• • 产品交付？ → 写 IIO 驱动，走标准子系统，支持 sysfs、中断、DMA；
• • 省电/实时性要求高？ → 必须内核驱动 + 中断 + workqueue。

写在最后

Linux 的强大，不仅在于它能跑在服务器、手机、路由器上，更在于它为硬件扩展提供了清晰的分层契约。

你知道哪一层该你负责，哪一层可以安心复用。
这种“各司其职”的设计哲学，才是开源系统的真正魅力。

下次当你接入一个新传感器，不妨先问自己：
“我是在造轮子，还是在搭积木？”